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

More Related Content

What's hot (20)

Similar to OpenStack Swift Debugging (20)

More from OpenStack Korea Community (20)

OpenStack Swift Debugging