manage inhouse openstack the hard way(kakao case study about 10,000 vms)
•
2 likes•384 views
https://leoh0.github.io/presentation-20161010/#/ kakao case study about managing 10,000 vms by openstack for private cloud management
Recommended
More Related Content
What's hot
What's hot (20)
Similar to manage inhouse openstack the hard way(kakao case study about 10,000 vms)
Similar to manage inhouse openstack the hard way(kakao case study about 10,000 vms) (20)
More from 어형 이
More from 어형 이 (9)
manage inhouse openstack the hard way(kakao case study about 10,000 vms)
- 1. MANAGE INHOUSE OPENSTACK THE HARD WAY Eohyung Lee https://leoh0.github.io/presentation-20161010
- 2. ABOUT ME so ware engineer(라고 쓰고 cloud engineer 아니.. openstack engineer.. A.K.A VM dealer) 개발, 리서치(라고 쓰고 온갖 삽질), 운영, 아키텍팅등 ( ~현재) 현재약10000+ VMs, 4 regions grizzly -> havana -> icehouse -> juno -> kilo 업그레이드 ( ~2014) public cloud storage service in KT about 3 years 이어형 private cloud service in kakao about 3 years
- 4. 또그 주제인가? 인가 싶지만 오늘은특정한코드관리만따놓고 이야기를 재탕
- 5. OPENSTACK IN KAKAO kfield vagrant + chef기반배포코드 vagrant-libvirt + openvswitch + quagga 등으로 linux box에서cluster 형태로테스트및배포코드개발 openstack code 주요repository 미러링 특정릴리즈의stable branch에 custom commit 들을패치해서사용
- 6. 왜KFIELD를만들었는가? 당시마땅한배포프로젝트는없어서.. 오픈소스배포코드들은특수한상황에 맞게만되어있어서사용못함 오픈소스배포코드들은openstack보단배포코드전문가가 작성을많이하여디테일한관리가 부족함 네트워크아키텍쳐에맞는구성을하려면all-in-one이아닌 cluster 형태가 필요함 network의가상화가 필요 ex.) bgp 아키텍쳐를테스트를위한quagga
- 7. 사실은.. chef code로거의다짜놔서.. 초기엔virsh로만든클러스터에chef로배포 나중에 vagrant-libvirt 를붙이면서 kfield(kakao + field)라이름지음 누군가 누군가
- 8. 테스트시네트워크가상화가 왜필요한가? 초창기 테스트모습 provider network 를테스트하기 위해서는필수
- 9. 배포코드구성 대부분프로젝트기준으로아래에틀에서크게 벗어나지않음 1. 패키지설치<= patch 2. 컨피그 변경 3. DB 마이그레이션 4. 프로세스시작 5. 부트스트래핑
- 10. 뭘PATCH 하는가? 1. 해당버전때적용안된bugfix 2. 쓰고 싶으나아직못쓰는추가적인feature 3. custom codes
- 12. 왜처음에VLAN을선택했었나? private cloud 에서는tenant private network이필수는아님 tunneling network를쓰기 위해선mtu 지옥과 en/decapsulation 가속이필요( $$ ) 당시엔openvswitch 아키텍쳐는neutron-plugin-agent 가 restart 할시모든자신의네트워크정보를neutron-server로 부터받아옴 tunneling network는full mesh 정보를구축하면대량의 RPC call이일어남 더불어네트워크초기화까지일어났기 때문에만약대량의 RPC call로rabbitmq 장애발생시네트워크가 복구 안됨
- 13. 하지만VLAN을쓰기시작하면.. large L2가 불가능 전용랙이아닐시switch port 단위로network admin이작업 필요 neutron segement id는(vlan id)는network 단위기 때문에 vlan : subnet = 1 : n 을지원해야함
- 15. CUSTOM CODES를 왜UPSTREAM에올리지않는가? 1. 스페셜케이스들이기 때문에.. 그 이유외에는 2. 시간부족& 노력부족 (master branch와stable branch 코드를다봐야하는아픔이..)
- 16. 아무튼어떻게 패치하나? (과거) PATCH_FILE ... diff --git a/keystone/common/config.py b/keystone/common/config.py index 85c49f8..b455d5f 100644 --- a/keystone/common/config.py +++ b/keystone/common/config.py @@ -69,6 +69,8 @@ FILE_OPTIONS = { '(eg /prefix/v2.0) or the endpoint should be found o 'a different server.'), + cfg.IntOpt('public_workers', default=1), + cfg.IntOpt('admin_workers', default=1), cfg.StrOpt('onready', help='onready allows you to send a notification when the ... PATCH!! apt-get install -y keystone cd /usr/lib/python2.7/dist-packages patch -p1 -i ${PATCH_FILE}
- 17. 패치관리가 힘듬.. (과거) 한프로젝트에여러개 patch가 생기면서patch 하는순서를잘 관리해야함 패치를업데이트해야되면이후패치전체를다시수정해야함 배포하다package가 업데이트되면서예상못한타이밍에 patch가 실패하는일들이발생
- 18. 결국 SOURCE LEVEL 로설치(현재) debian package를repackaging 했으나 dependency 관리가 지옥 결국 version control 할수있는git을사용 main repo를mirroring 하면서custom commit 들을 버전마다지속적인rebase가 필요
- 19. 이왕SOURCE로설치하는김에PYTHON VERSION도고정 여러버전의os 들을섞어서써야하는 일들이발생 로특정version의python을 하도록함 이후모든python-path 들에대한관리가 필요 pyenv 설치
- 20. 결국 그러려면PYTHON LIBRARY 관리필요 를이용해서전체requirements 를설치 이걸 매번반복하면엄청난양을compile 하는것을볼수있음.. 그렇기 때문에가능한wheel 로 시간 절약가능 requirements 미리compile 해두면 추후에아래와같이사용 # 여기에서 전체 requiments 설치 cd openstack/requirements pip install --use-wheel --no-index --find-links=${URL} -c upper-constraints.t # 위에서 전체 requiments 가 설치 되었으므로 아래에서는 거의 코드만 설치됨 cd openstack/keystone pip install .
- 21. 이렇게 되었을때배포코드구성 패키지설치대신결국 1. pyenv 설치 2. python 설치 3. global requirements 설치 4. 코드설치
- 22. 그래서앞으로.. CONTAINER로배포가 필요 배포중간 문제가 생기기 시작하면 결국 container가 필요한가 싶어짐 하지만아직docker 외에별다른옵션은없고 docker로도 관리가 불편함 아무튼docker(>= 1.10)기준으로 network namespace privileged, host 자원을쓰는것이필요함
- 23. 아무튼현재상황(GIT)에서 다음RELEASE 로업데이트해야하면필요한게.. 패치를새로운release로rebase 필요 (Welcome to Rebase Hell) 새로운requirements 에대한python library 관리 물론버그는덤
- 24. 다만UPGRADE CODE는그렇게 복잡하지않음 (준비) juno upgrade시준비한실제code
- 25. chef 종료 업로드 control service stop compute service stop knife ssh roles:* 'service chef-client stop' berks install && berks upload --force # for safe reupload knife role from file roles/*.rb knife environment from file environments/$(chefvm current).rb knife ssh roles:*control* '/root/bin/os-service.sh stop' knife ssh roles:*compute* '/root/bin/os-service.sh stop'
- 26. 다만UPGRADE CODE는그렇게 복잡하지않음 (업그레이드) lb db control compute dhcp chef-client -c /etc/chef/client.rb -l fatal -F doc rm -rf /opt/openstack chef-client -c /etc/chef/client.rb -l fatal -F doc rm -rf /opt/openstack chef-client -c /etc/chef/client.rb -l fatal -F doc rm -rf /opt/openstack chef-client -c /etc/chef/client.rb -l fatal -F doc ps -ef | grep neutron-ns-metadata-proxy | grep -v grep | awk '{print $
- 28. 결국 테스트가 필요 뭐세상일이쉽게 될리는.. 싶지만서도..
- 29. UNIT TEST tox 라고 심플하게 적고 싶으나사실은인스톨할정도의패키지와 library 들이미리설치되어있어야함 일반적으로미리.tox용venv를 해서 사용캐슁 빠르게
- 30. INTEGRATION TEST tempest + (rally) 라고 심플하게 적고 싶으나사실은이게 제일지옥임 왜냐하면tempest, rally는우선stable branch가 없음 tempest의config는floating ip를켰다는전제하에돌아가는 코드가 엄청나게 많음(그리고 이런류의코드가 많음..) 아무튼tempest를자신의환경에맞추는작업을해야함 이것도docker로말아서쓰고 있음
- 31. 테스트성공.. ㅠㅠ 이후엔worker간 서로테스트를방해하는케이스때문에그냥 concurrency=1 을선택하게 됨..
- 32. 마지막으로.. 에러관리 openstack에서발생하는error 로그를 처음으로다받아보게 된다면.. 아래와같이..
- 33. LOG 기반알림 로전체log에서ERROR 로그만수집해서알림받음 하지만엄청난양의로그를받을수있기 때문에filtering등의방 법들이필요 하지만사실동일한에러라도다양한케이스일경우들이많음 ELK류
- 34. OPENSTACK NOTIFICATION QUEUE 기반알림 로notification.error 를알림 client error 등에도빠르게 대응가능 이후에도다양한디버깅 용도로사용가능(event의context가 자세하게 기록) stacktach
- 35. Q & A
- 36. INHOUSE OPENSTACK을했던일중에가장큰일 에대한이야기를한가지.. 2015 3월- 달리는기차의엔진갈아끼우기 openvswitch 에서linux bridge 로네트워크 전체무중단교체 당시스크립트
- 44. 감사합니다.