OpenStack Swift Debugging

OpenStack Swift Debugging
OpenStack Korea Community Study Organizer
장태희

List
▪ What is Swift?
▪ Swift APIs
▪ How to debug?

2017년 Openstack Swift 분석 스터디
▪ Study Lead : 조성수
▪ Study Period : 2017.04.11 ~ 2017.07
▪ 장소 제공 : Naver D2
▪ 산출물 공유 : Github(https://git.io/vdvHv)

What is Swift?
▪ OpenStack Object Store project(Object Storage)
▪ Store data as objects.
▪ Offers cloud storage software, store and retrieve lots of data
with a simple API.
▪ swift-proxy, account, container, object로 구성됩니다.
▪ Swift-proxy는 account, container, object를 관리, Object API를 제공
▪ Account, Container는 DB로 데이터가 관리되며, Object는 저장공간에
직접 저장되는 방식으로 설계 되어 있습니다.
▪ User는 API를 통하여 데이터를 저장하거나 다운로드
For more information, please visit https://docs.openstack.org/swift/latest
Source) http://naleejang.tistory.com/104

Swift URl
▪ http://host/v1/account/container/object
▪ v1 : api version
▪ account : account name in swift
▪ container : container name
▪ object : object name
For more information, please visit https://docs.openstack.org/swift/latest

Swift APIs
▪ account – accounts in swift.
▪ container – same concept of Amazon S3 bucket. objects are stored in
container.
▪ object - data such as documents, files, and movies. Available to save w
ith metadata

Swift APIs
▪ account – accounts in swift.

Swift APIs
▪ container – same concept of Amazon S3 bucket. objects are stored in
container.

Swift Components
▪ proxy-server
▪ Provide Swift API and relay requests to backend servers(accout,
container, object)
▪ account-server
▪ Save swift account information. Shows information amounts of
container per accounts, storage usage.
▪ container-server
▪ Save container information of accounts

Swift Components
▪ object-server
▪ Store real objects. Each objects has basically 3 replications.
▪ Daemon
▪ Numeral daemons must be executed due to the fact that swift is
eventual consistency system so that it should sustain consistency.

▪ Create a loopback device for storage
▪ ignore erasurecode library

Make VM for OpenStack Test Bench

Pycharm Development Environment
▪ Same swift code on Native OS and Virtual Machine.
▪ Required : Pycharm Professional Edition.

Summary) koain 김영우 - https://git.io/v5jpA

▪ tempauth.py
▪ swob.py
▪ crossdomain.py
▪ base.py
▪ ratelimit.py
▪ wsgi.py
▪ healthcheck.py
▪ eventlet/wsgi.py
▪ BaseHTTPSServer.py
▪ SocketServer.py
▪ greenpool.py

/swift/common/middleware/tempauth.py
▪ token 인증을 처리하는 부분
▪ URL은 어떻게 제공되는가?
▪ 원하는 대상 정하기
▪ request에 보낸 내용을 가지고 보기
▪ request를 보내는 것이 없으면 log를 가지고 (log가 찍혔다면
code가 지나간 자리이므로) 해당 부분을 검색하여 string을 검
색

▪ account_user = account + ':' + user -> 유저 인증 시작 부분(user와
group이 정상적인지 이전에 확인)
▪ if self.users[account_user]['key'] != key -> 키 검사
▪ account_id = self.users[account_user]['url'].rsplit('/', 1)[-1] -> 계정
id 가져오기
▪ if not token: -> token이 생성되는 과정을 볼 수 있다
▪ resp = Response(request=req, headers={ -> token이 모두 발급 된
것을 확인
▪ X-Auth Token을 언제 가져오는가?
▪ token = env.get('HTTP_X_AUTH_TOKEN',
env.get('HTTP_X_STORAGE_TOKEN'))

▪ 유효성 검사
▪ breaking point : groups = self.get_groups(env, token)
▪ memcache_token_key = '%s/token/%s' % (self.reseller_prefix,
token)
▪ memcache_token_key = '%s/token/%s' % (self.reseller_prefix,
token)
▪ token의 문자열을 검사 하는 것이 아니라, memcache에서 무엇
인가를 가져와서 비교하는구나 라고 알게 됨.

/swift/commom/middleware/proxy-logging.py
▪ Logging middleware for the Swift proxy.
▪ `client_ip remote_addr datetime request_method request_path
protocol status_int user_agent auth_token bytes_recvd
bytes_sent client_etag transaction_id headers request_time
source log_info request_start_time request_end_time`
▪ url 인코딩되고, 스페이스로만 구분되므로 `split()`으로 간단히
구분이가능

▪ `remote_addr` : `REMOTE_ADDR` 환경변수 값
▪ `client_ip` : `X-Forwarded-For` 해더, `x-Cluster_Ip` 해더,
`REMOTE_ADDR` 환경 변수 값들을 나타낸다.
▪ `source` : WSGI 환경에서의 `swift.source` 를 나타낸다. 요청을 생성
한 코드를 나타냄
▪ `log_info`WSGI 환경에서의 `swfit.log_info` 값을 나타낸다.
▪ `x-delete-at` 값이나 일반 로그 정보에서 감지할 수 없는 <b>뒤에서
동작하는</b> 코드들에 대한 추가 정보를 내보냄.
▪ 로그 추가시`env.setdefault('swift.log_info', []).append(your_info)` 를
이용하여 다른 사람들과의 로그와 충돌이 없도록 해야 함.
▪ 헤더 값이 없거나, 누락된 값, 0은 일반적으로 `-` 로 표기.

▪ config 값
▪ `self.log_hdrs`
▪ àccess_log_haders` 가 있으면 해당 값을 읽어오고 없으면
`log_headers`를 읽어오는데 그것도 없으면 `no`로 설정
▪ `log_hdrs_only` : àccess_log_headers_only` 값이 존재하면
`log_hdrs_only` 값에다가 리스트로 가지고 있음.
▪ `self.valid_methods` : àccess_log_statsd_valid_http_methods` 값을
가져오며, 없으면 `log_statsd_valid_http_methods` >
`GET,HEAD,POST,PUT,DELETE,COPY,OPTIONS` 순으로 값을 가져오게
된다.
▪ 해당내역도 각 항목별로 string list로 구성된다.

DLO / SLO
▪ /swift/commom/middleware/dlo.py
▪ D(Dynamic)LO : 파일을 무한정 올릴 수 있다. multipart 종료 시점을 알
수 없음.
▪ req = Request() 객체를 어떻게 잘 활용하는지, Debugging point, 분기
를 눈에 익히는것이 목적
▪ /swift/commom/middleware/slo.py
▪ S(Static)LO : multipart 업로드 종료 이후 더이상 part 업로드 불가.

Custom Middleware Development
▪ `def filter_factory`
▪ closer 기법을 통한 작성
class MyMiddleware:
def filter_factory(global_conf, **local_conf):
conf.update
def my_filter(app):
return MyMiddleware(app, conf)
return my_filter
For more information, https://docs.openstack.org/swift/pike/development_middleware.html

Custom Middleware Development
▪ pipeline에서 동작시 wsgi.py module이 어느 클래스를 로드 할지
결정.(paste.filter_factory 부분)
▪ wsgi가 각 middleware의 클래스들을 초기화 시켜준다.
▪ 각 middleware별 특정 변수들은 local_conf에 저장
▪ app parameter는 다음에 호출 할 middleware를 가리킴.
▪ 문서에 나온것과 달리 middleware는 따로 repository를 만들어서
관리. 이후 설치할 수 있는 설치형으로 만듬.
▪ setup.py에 pbr 설정을 한 뒤 setup.cfg에 swift를 설치하듯이 설치.

proxy/server.py __call__
▪ wsgi가 부르는 함수, 한번 인증된 키에 대해서는 memcached
가 가지고 있어 Keystone으로 갈 필요가 없음
▪ proxy server -> proxy/containers/server.py 가 핵심

Cluster
▪ cluster에서 region을 생성한다.(여러개가 될 수 있음)
▪ 여러개의 region
▪ region 간은 독립된 환경이어야 함. (전기, 네트워크 등)
▪ region 안에 여러개의 zone
▪ 여러개의 rack을 묶어 region을 만들 수도 있고, 하나의 데이터
센터를 region으로 할 수도 있다.
▪ 각 region은 독립된 전원과 네트워크 등을 사용해야 한다.

Cluster
▪ zone은 하나의 rack이라고 보면 된다.
▪ zone은 하나의 랙이라고 봐도 무방
▪ 한 열이 zone이 될수도, 랙 여러개가 zone이 될수도 있음
▪ zone안에 여러개의 node
▪ node는 서버라고 봐도 무방
▪ node안에 여러개의 하드디스크
▪ node는 각 서버 장비라고 보면 된다.
▪ hash 알고리즘은 md5를 기본으로 사용.

분산 시스템 - consistence hash ring
Source) http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html

Account / Container
▪ account와 container는 database에 접근하는 코드 구조가 비슷
▪ account/server.py
▪ PUT -> proxy 서버에서 request를 받을 때에는
http://prox_svr/v1/account/container/obj
▪ PUT에서 database로 request를 보낼 때에는
http://account_server/v1/sdb1/70/account/obj 로 바뀌어 보내
게 된다.
▪ account 생성 == db file 생성

Account / Container
▪ db.py -> initialize == sqlite에 table을 만드는 것 까지만 진행
▪ PUT 요청 -> db 파일을 하나 생성하고 원하는 이름은 rename
으로 db 파일을 생성한다. PUT 명령이 오면 실제 sqlite에 바로
쓰는것이 아니라 pending 파일에 기록하고, pending 파일이 일
정 capacity를 넘어서면 .lock 파일로 모든 요청을 잠시 막고 db
에 기록한다.

Account / Container
▪ GET 요청 -> 모든 요청을 잠시 막고 pending에 있는 것을 db에
merge시킨 뒤 db를 읽어온다.
▪ DELETE -> table field에 DELETED라고 flag 표시만 하고 실제
지우지는 않는다. 나중에 auditor daemon이 돌면서 실제 파일
을 지운다.

OpenStack Swift Debugging

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to OpenStack Swift Debugging

Similar to OpenStack Swift Debugging (20)

More from OpenStack Korea Community

More from OpenStack Korea Community (20)

OpenStack Swift Debugging