manage inhouse openstack the hard way(kakao case study about 10,000 vms)
TRANSCRIPT
MANAGE INHOUSE OPENSTACKTHE HARD WAY
Eohyung Lee
https://leoh0.github.io/presentation-20161010
ABOUT ME
so�ware engineer(라고 쓰고 cloud engineer 아니..openstack engineer.. A.K.A VM dealer)개발, 리서치(라고 쓰고 온갖 삽질), 운Ý, 아키텍팅 등
( ~현재)
현재 약 10000+ VMs, 4 regionsgrizzly -> havana -> icehouse -> juno -> kilo 업그레이드
( ~2014) public cloud storage service in KT about 3 years
이어형
private cloud service in kakao about 3 years
✨오늘의 주제✨
카카오는 openstack을 어떻게 관리하고 있는가?
(힘들게ㅠㅠ)
또 그 주제인가?인가 싶지만
오늘은 특정한 코드관리만 따놓고 이야기를재탕
OPENSTACK IN KAKAO
kfield
vagrant + chef기반 배포 코드vagrant-libvirt + openvswitch + quagga 등으로 linux box에서 cluster 형태로 테스트 및 배포 코드 개발
openstack code
주요 repository 미러링특정 릴리즈의 stable branch에 custom commit 들을 패치해서 사용
왜 KFIELD를 만들었는가?
당시 마땅한 배포 프로젝트는 없어서..
오픈소스 배포 코드들은 특수한 상황에 맞게만 되어 있어서 사용 못함오픈소스 배포 코드들은 openstack보단 배포 코드 전문가가 작성을 많이하여 디테일한 관리가 부족함
네트워크 아키텍쳐에 맞는 구성을 하려면 all-in-one이 아닌 cluster 형태가 필요함
network의 가상화가 필요ex.) bgp 아키텍쳐를 테스트를 위한 quagga
사실은.. chef code로 거의 다 짜놔서..
초기엔 virsh로 만든 클러스터에 chef로 배포나중에 vagrant-libvirt 를 붙이면서 kfield(kakao + field)라 이름지음
누군가
누군가
테스트시 네트워크 가상화가 왜 필요한가?초창기 테스트 모습
provider network 를 테스트 하기 위해서는 필수
배포 코드 구성�부분 프로젝트 기준으로 아래에 틀에서 크게 벗어나지 않음
1. 패키지 설치 <= patch2. 컨피그 변경3. DB 마이그레이션4. 프로세스 시작5. 부트스트래핑
뭘 PATCH 하는가?1. 해당 버전때 적용안된 bugfix
2. 쓰고 싶으나 아직 못쓰는 추가적인 feature
3. custom codes
CUSTOM CODES를 왜 쓰는가?다른 이유도 많지만 그중에서도
우리에겐 선택할 수 있는 네트워크 아키텍쳐가 제한적이었음
왜 처음에 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 장애 발생시 네트워크가 복구 안됨
하지만 VLAN을 쓰기시작하면..large L2가 불가능전용랙이 아닐시 switch port 단위로 network admin이 작업필요
neutron segement id는(vlan id)는 network 단위기 때문에vlan : subnet = 1 : n 을 지원해야함
CUSTOM CODES를 왜 UPSTREAM에 올리지 않는가?
1. 스페셜 케이스 들이기 때문에.. 그 이유 외에는
2. 시간부족 & 노력부족 (master branch와 stable branch 코드를 다 봐야하는 아픔이..)
아무튼 어떻게 패치하나? (과거)PATCH_FILE
...diff --git a/keystone/common/config.py b/keystone/common/config.pyindex 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 on ' '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 keystonecd /usr/lib/python2.7/dist-packagespatch -p1 -i ${PATCH_FILE}
패치 관리가 힘듬.. (과거)한 프로젝트에 여러개 patch가 생기면서 patch 하는 순서를 잘관리해야함
패치를 업데이트해야 되면 이후 패치 전체를 다시 수정해야 함배포 하다 package가 업데이트 되면서 예상 못한 타이밍에patch가 실패하는 일들이 발생
결국 SOURCE LEVEL 로 설치 (현재)debian package를 repackaging 했으나 dependency 관리가 지옥결국 version control 할 수 있는 git을 사용main repo를 mirroring 하면서 custom commit 들을 버전마다 지속적인 rebase가 필요
이왕 SOURCE로 설치하는 김에 PYTHONVERSION도 고정
여러 버전의 os 들을 섞어서 써야하는 일들이 발생
로 특정 version의 python을 하도록 함이후 모든 python-path 들에 �한 관리가 필요pyenv 설치
결국 그러려면 PYTHON LIBRARY 관리 필요를 이용해서 전체 requirements 를 설치
이걸 매번 반복하면 엄청난 양을 compile 하는것을 볼 수 있음..그렇기 때문에 가능한 wheel 로 시간 절약 가능
requirements
미리 compile 해두면
추후에 아래와 같이 사용# 여기에서 전체 requiments 설치cd openstack/requirementspip install --use-wheel --no-index --find-links=${URL} -c upper-constraints.txt -r # 위에서 전체 requiments 가 설치 되었으므로 아래에서는 거의 코드만 설치됨cd openstack/keystonepip install .
이렇게 되었을때 배포 코드 구성패키지 설치 �신 결국
1. pyenv 설치2. python 설치3. global requirements 설치4. 코드 설치
그래서 앞으로.. CONTAINER로 배포가 필요배포 중간 문제가 생기기 시작하면 결국 container가 필요한가 싶어짐하지만 아직 docker 외에 별다른 옵션은 없고 docker로도 관리가 불편함아무튼 docker(>= 1.10)기준으로
network namespace
privileged, host 자원을 쓰는것이 필요함
아무튼 현재상황(GIT)에서 다음 RELEASE 로 업데이트 해야하면 필요한게..
패치를 새로운 release로 rebase 필요 (Welcome to Rebase Hell)새로운 requirements 에 �한 python library 관리물론 버그는 덤
다만 UPGRADE CODE는 그렇게 복잡하지 않음 (준비)
juno upgrade시 준비한 실제 code
chef 종료
업로드
control service stop
compute service stop
knife ssh roles:* 'service chef-client stop'
berks install && berks upload --force # for safe reuploadknife role from file roles/*.rbknife 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'
다만 UPGRADE CODE는 그렇게 복잡하지 않음 (업그레이드)
lb
db
control
compute dhcp
chef-client -c /etc/chef/client.rb -l fatal -F doc
rm -rf /opt/openstackchef-client -c /etc/chef/client.rb -l fatal -F doc
rm -rf /opt/openstackchef-client -c /etc/chef/client.rb -l fatal -F doc
rm -rf /opt/openstackchef-client -c /etc/chef/client.rb -l fatal -F docps -ef | grep neutron-ns-metadata-proxy | grep -v grep | awk '{print $2}'
오! 다 된거 같은데 PRODUCTION에 적용해 볼까..
결국 테스트가 필요
뭐 세상일이 쉽게 될리는.. 싶지만서도..
UNIT TESTtox
라고 심플하게 적고 싶으나 사실은 인스톨 할정도의 패키지와library 들이 미리 설치 되어 있어야 함일반적으로 미리 .tox용 venv를 해서 사용캐슁 빠르게
INTEGRATION TESTtempest + (rally)
라고 심플하게 적고 싶으나 사실은 이게 제일 지옥임왜냐하면 tempest, rally는 우선 stable branch가 없음tempest의 config는 floating ip를 켰다는 전제하에 돌아가는코드가 엄청나게 많음(그리고 이런류의 코드가 많음..)아무튼 tempest를 자신의 환경에 맞추는 작업을 해야함이것도 docker로 말아서 쓰고 있음
테스트 성공.. ㅠㅠ
이후엔 worker간 서로 테스트를 방해하는 케이스 때문에 그냥concurrency=1 을 선택하게 됨..
마지막으로.. 에러 관리openstack에서 발생하는 error 로그를 처음으로 다 받아보게 된다면.. 아래와 같이..
LOG 기반 알림로 전체 log에서 ERROR 로그만 수집해서 알림 받음
하지만 엄청난 양의 로그를 받을 수 있기 때문에 filtering등의 방법들이 필요하지만 사실 동일한 에러라도 다양한 케이스 일 경우들이 많음
ELK류
OPENSTACK NOTIFICATION QUEUE 기반 알림로 notification.error 를 알림
client error 등에도 빠르게 �응가능이후에도 다양한 디버깅 용도로 사용가능 (event의 context가자세하게 기록)
stacktach
Q & A
INHOUSE OPENSTACK을 했던일중에 가장 큰 일에 �한 이야기를 한가지..
2015 3월 - 달리는기차의 엔진 갈아끼우기openvswitch 에서 linux bridge 로 네트워크 전체 무중단 교체당시 스크립트
감사합니다.