뉴타닉스 클러스터에 대한 인상

얼마만에 쓰는 기술에 대한 글인지 모르겠다. 그동안 기술에 대한 글을 적을 일이 없다가 이번에 이직하면서 뉴타닉스에 대해 만지게 되었고, 한 6개월 정도 되었으니 적어봐도 되겠다 싶어서 적어본다.

뉴타닉스는 중소 호스팅사에 다니다가 가상화 쪽 일을 시작하면서 알게된 회사이다. 중소 호스팅 회사는 아무래도 지금은 주력사업이 SI 이다 보니 호스팅에 대해 투자가 적은 편이었고, 하드디스크에 대한 장애가 잦았다. 그러다보니 서비스 순단도 잦았고, 백업은 잘 되어 있었지만, 백업 주기 때문에 유실되는 데이터도 있었고, 메일서버를 직접 운영하는 것에 대한 스트레스도 꽤나 있는 편이었다.(GMAIL은 이상한 이유로 메일을 스팸 차단하면서 풀어주지 않는다. 그리고 회사는 오래된 SMTP 서버 버전을 사용해서 DMARC 를 지원하지 않았다.)

반면 지금 회사는 국내 한 대기업 계열사에 뉴타닉스 장비를 납품하고, 유지보수 하는 일인데 일단 노드에 대한 장애가 생겨도 서비스 장애가 없다는 점이 좋았고, 문제가 생기면 뉴타닉스나 장비 파트너사에 케이스를 열어 처리할 수 있다는 점도 좋았다. 기술적으로의 성장이 그렇게 많이 필요한 건 아니지만, 아키텍처의 이해와 고객사별로 특이점을 챙겨야한다는 점에서 조금 까다롭긴 하다.

뉴타닉스, HCI란?

CVM과 하이퍼바이저에 대해서

뉴타닉스에서 제공하는 서버와 서비스들은 HCI 를 위한 제품들이다. HCI는 기존에 서버 - SAN 스위치 - 스토리지 구조를 합쳐놓은 것으로 복잡한 스토리지 구조를 일체형으로 만들어놓은 것이다.하이퍼컨버지드인프라 라고 하는데 그래서 확장과 축소도 유연하게 가능하며, 관리 포인트가 줄어든다는 장점이 있다.

기본적으로 뉴타닉스는 클러스터 형태로 구성되며, 3개 노드가 1개 클러스터를 구성하는 것이 정석이다. 1개 노드 클러스터나 2개 노드 클러스터도 가능은 하지만 가용성을 보장할 수 없으므로 3개 노드 클러스터를 권장한다. 이렇게 구성하게 되면 클러스터 안에서 노드들은 추상화가 되며 추가적으로 컴퓨팅 리소스가 필요한 경우 노드를 추가할 수 있다.

뉴타닉스 클러스터는 자체적으로 제작한 하이퍼바이저인 AHV 를 사용한다. 물론 델이 인수하고, 세계적으로 많이 쓰는 VMware의 ESXi나 마이크로소프트의 Hyper-V 도 지원하긴하지만, 라이선스의 비용 문제 등으로 인해 VMware VDI 솔루션을 쓰는 것이 아니면 주로 AHV를 사용한다. 오래전부터 사용한 고객들의 경우에는 AHV가 출시하기 전이라 ESXi를 사용하는 경우가 많긴 했다.

이 AHV는 CentOS 7 기반이며 KVM/QEMU 기반으로 동작한다. 이런 하이퍼바이저 위에 VM 을 올려서 사용하는 형태인데 네트워크, 스토리지 IO를 담당하는 CVM 이라는 것이 기본적으로 노드당 한개씩 생성된다. 역시 이 CVM도 CentOS 7 기반으로 CentOS 7 지원이 끝난 다음에는,, 어떤 OS를 쓰게 될지 궁금하긴 하다. 사실상 이 CVM이 뉴타닉스 클러스터의 꽃이다. CVM은 Controll VM의 약자로 네트워크, 스토리지 IO 뿐만 아니라 클러스터를 코디네이트하는 아파치 주키퍼, 메타데이터를 저장하는 아파치 카산드라 등의 전반적인 클러스터 서비스들을 실행한다. 그래서 대부분 서비스 확인 등을 할 때 CVM에 SSH 접속을 많이 하게 된다. 또한 뉴타닉스 클러스터 OS 인 AOS도 CVM 위에 올라가게 된다.

ESXi 의 경우 CVM 같은 VM을 만드는 것이 아니라 별도로 작성된 유닉스 계열의 커널인 VMKernel 에서 담당하는 것으로 알고 있다. 이런 경우 스토리지 컨트롤러의 장애 상황의 경우 ESXi는 하이퍼바이저에도 영향을 끼칠 수 있는 것에 비해 뉴타닉스는 VM 형태라서 서비스 및 하이퍼바이저에 끼치는 영향은 적은 것으로 알고 있다.

하지만 VMWare는 어쨌거나 HCI 뿐만 아니라 업계 표준에 가까울 정도로 많이 쓰이고 있어서,, 한번은 다루어봤으면 좋겠다는 생각이 든다. 물리서버에 VMWare를 올려서 쓰는 회사도 제법 많으니까 말이다.

클러스터 조율, 주키퍼(zookeeper)에 대해서

뉴타닉스에는 RF2, RF3 라는 개념이 있다. 뉴타닉스는 가용성을 보장하기 위해 3개 노드 이상을 한 개 클러스터로 만드는 것을 권장한다. 이때 데이터의 복제본을 만드는데 RF2는 데이터 복제본을 1개 만들어 2개를 가지고 있는 것이고, RF3는 데이터복제본을 2개 만들어 3개를 가지고 있는 것이다. 이때 RF2는 최소 3개 노드 이상을, RF3는 최소 5개 노드 이상을 권장한다. 얼마전에 알게 된 것인데 이게 주키퍼와도 관련이 있다는 사실을 알게 되었다.

RF2 일 때 주키퍼는 3개 생성이 되고, 그 중 1개가 리더로 선정된다. 그래서 만약 1개 노드가 장애가 발생한 상태에서 다른 노드가 장애가 발생했을 때 그 노드가 주키퍼 리더일 경우 아예 클러스터가 깨지는 경우가 발생한다. 반면 다른 노드 장애가 주키퍼 리더가 아니고, 스토리지 장애가 아닐 경우 다른 노드 장애처리를 하면 클러스터는 깨지지 않는다.

노드가 4개로 구성되어도 RF2 일 경우 주키퍼는 4개가 다 올라가는데 쿼럼에는 3개만 올라가게 된다. 그 이유는 네트워크 이슈 등으로 다른 사이트에 있는 노드와의 연결이 끊어지거나 외부 클라이언트 등과의 연결이 끊어졌을 때에도 데이터정합성을 위해 주키퍼 리더는 하나가 선출 되어야한다. 그래서 과반수 이상 동의가 필요한 알고리즘을 채택하였다.

조금 더 자세히 설명을 해보겠다. 주키퍼 리더는 Quorum (쿼럼) 이라고 하는 합의체가 의사를 진행시키거나 의결하는데 필요한 최소한도의 인원수가 동의해서 선출된다. 주키퍼 리더는 주키퍼 팔로워 혹은 클라이언트로부터 받은 트랜잭션 요청을 팔로워들에게 전달하면서 트랜잭션 요청을 한다. 이때 Quorum 이 2면 2개 노드에게 Quorum이 3이면 3개 노드에게 보낸다. 그럼 그 노드는 트랜잭션 수행을 해도 된다는 ACK 응답을 보내고, 리더는 모든 ACK 응답을 받으면 COMMIT 을 통해 트랜잭션을 지시한다. 그리고 트랜잭션이 끝나고 나면 클라이언트에 완료를 반환한다. 읽어보면 알겠지만 이 Quorum이 RF 계수이다. 3개 노드 클러스터 RF2로 설정하였을 때 이런식으로 트랜잭션은 계속 2개 노드에 작성되고 있다. 그러다 한 개 노드가 죽으면 주키퍼들끼리 리더를 선출하는데 과반수가 2개 이므로 리더 선정이 가능하다. 여기서 다시 한 노드가 죽게 됐을 때 살아 있는 노드 1개가 주키퍼 리더라면 나머지 노드들이 살아났을 때 주키퍼 리더를 기준으로 데이터를 트랜잭션하면 되므로 클러스터가 깨지지 않지만, 주키퍼 리더가 죽는다면, 리더를 선출하지 못하니까 트랜잭션을 마무리 하고 나머지 노드들도 OFF 하게 되거나 클러스터가 깨지게 된다.

따라서 이런 절차 때문에 클러스터 노드가 짝수개일 경우 쿼럼에는 포함시키지 않는 것이며, 권장하지 않는 것이다.

뉴타닉스 스토리지에 대해서

뉴타닉스에서 사용하는 파일 시스템은 분산 파일 시스템이다. 그래서 여러개의 스토리지를 하나의 풀로 만들어서 사용한다. 또한 뉴타닉스 노드들은 SSD를 반드시 필요로 한다. 왜냐하면 뉴타닉스 AOS는 읽기/쓰기를 더 빨리 처리하기 위해 캐시처럼 사용하기 때문이다. 뉴타닉스에서 SSD는 CVM /home, 카산드라 등의 메타데이터, OpLOG 라고 하는 쓰기 버퍼, 영구 스토리지(Extent Store)로 나누어서 사용한다. 반면 HDD는 큐레이션용 예약 데이터를 제외하면 모두 영구 스토리지로 사용한다. 뉴타닉스는 쓰기 요청이 오면 모든 CVM OPLog에 복제하는데 이는 CVM 부하에 따라 동적으로 N개가 선택된다. 복제하고 난 다음에는 영구 스토리지에 저장되며 데이터에 중요도에 따라 SSD 스토리지에서 HDD 스토리지로 이동하는 등의 부하 분산을 거친다. 반대로 읽을 때는 메모리 - OpLOG - SSD 영구스토리지 - HDD 영구스토리지 순으로 읽는다. 그래서 SSD가 꼭 필요하다고 했던 것이며, 올플래시 노드 같은 경우에도 NVME와 SATA SSD로 나뉘어 있으면 역시 NVME에 OPLog 등이 할당된다. 해당 작업은 스타게이트라는 프로세스를 통해 수행된다.

뉴타닉스에서 제공하는 서비스, 서버

어플라이언스

어플라이언스는 전용하드웨어라는 뜻이다. 뉴타닉스에서는 슈퍼마이크로에 외주를 줌으로써 뉴타닉스 자체 하드웨어를 만들고 있다. 앞에서 보면 뭔가 상어가 입벌리는 모양으로 무척이나 귀엽게 생겼다. 다른 벤더들도 이런 형태의 어플라이언스를 만드는지 모르겠다. 뉴타닉스 NX-3060 시리즈가 미들급인편인데 이 장비는 특이하게도 뒤에 블레이드 서버를 장착하여 1개 블럭에 최대 4개까지 노드를 장착할 수 있겠끔 만들었다. 그래서 전면부, 커버 뒤에 있는 디스크들도 노드별로 구획이 나누어져 있다. 서버 상면을 줄이는데에는 유리하긴 하나, 발열이나 성능등의 문제로 요즘은 NX-8150처럼 1블럭 1노드인 어플라이언스를 사용하고 있다.

뉴타닉스말고도 이런 어플라이언스를 제공하는 벤더들이 있다. 레노버의 HX, HP의 DX, 델의 HX 등이 있으며 호환이 되는 다른 서드파티 서버들에도 설치해서 운영할 수 있다. AHV와 AOS 는 파운데이션 VM을 통해 설치 된다. 역시 CentOS 7 기반의 VM으로 파운데이션 VM을 실행시킨 후 해당 VM IP로 http 접속을 하면 설치 페이지가 뜬다. 그러면 그 페이지에서 클러스터 설정과 IPMI ID, PW 등을 입력하면 타겟 서버에 AHV, AOS가 설치된다. ESXi 나 Hyper-V 역시 파운데이션 VM에 미리 업로드 하면 설치할 때 선택해서 설치할 수 있으며 주로 AOS에 동봉된 AHV로 설치하게 된다. 그래서 크게 장비를 타지 않으며 동일 버전 AHV, AOS 라면 클러스터 구성을 할 수 있고, 기존 클러스터에 노드 확장 역시 따로 설치한다음 확장이 가능하다. 다른 클러스터에서 사용하던 노드를 제거하고 확장할 때는 AHV와 AOS 버전을 현재 클러스터에 맞게 자동으로 업그레이드 한다.

서비스

기본적으로 설치가 완료가 되면 PRISM 을 통해 접속해서 관리할 수 있다. 프로즘은 웹 UI로 된 관리 툴인데 크롬 등에서 자체 서명된 인증서라고 접속이 불가할 수 있다. 그때는 this is unsafe 를 공백없이 타이핑하면 접속할 수 있다. 서브넷 구성, VM 생성 등 대부분의 작업은 프리즘에서 할 수 있으며 클러스터 상태 체크나 펌웨어 수동 업그레이드, 클러스터 STOP, START 등의 작업 시에만 CVM에 터미널로 접속하여 수행하게 된다.

프리즘은 기본적으로 GUI 이기 때문에 어렵지 않으며 클러스터 헬스체크 툴인 NCC HEALTH CHECK 를 통해 정기점검을 수행하게 된다. NCC 헬스체크에서는 미리 지정된 항목들에 대해 체크를 진행하며 그 정도에 따라 FAIL, ERROR, WARN, INFO 로 구분한다. 이때 ERROR는 해당 정보를 읽지 못했다는 뜻이므로 진짜 ERROR 일 수도 있고, 설정이나 미사용 기능일 수도 있으니 한번 더 확인이 필요하다.

아무래도 스토리지 가상화이고, 클러스터다보니 추가적으로 제공하는 기능들도 있다. 뉴타닉스 클러스터에서 쿠버네티스를 운용할 수 있는 NKE 라던지, VM 세트로 배포할 수 있는 Carbon 이라던지 NAS 같은 파일스토리지인 FILES, MINIO 같은 오브젝트 스토리지인 OBJECT 등이 있다.

고객사들은 주로 FILES를 많이 쓴다. NAS 용도로 사용하는 고객도 있고, VDI VM의 D 드라이브 용도로 사용하곤 한다. FILES의 NFS 공유 별도의 인증 없이 공유할 수 있으나, SMB의 경우 AD 인증을 하겠끔 되어 있어서 AD에 대해 잘 모른다면 처음 셋팅에서 애를 먹을 수 있다.

DR 및 백업 기능도 있다. 다른 클러스터 둘을 연결해서 DATA PROTECTION을 통해 스냅샷을 넘기는 형태인데 AWS 같은 퍼블릭 클라우드에서도 NC2라는 뉴타닉스 클러스터 상품이 있어 퍼블릭 클라우드로 DR이나 백업할 수도 있다.

FLOW라는 인바운드 아웃바운드 WAF 기능도 지원하고 있으며 전반적으로 데이터센터를 HCI로 현대화한다는 목표로 계속 서비스들을 출시하는 중이다.

단점

클러스터라는게 그렇듯 같은 노드 같은 OS, 한 개 클러스터라도 모든 노드 상태가 같을 수는 없다. 이런 경우 업그레이드 작업 등을 할 때 노드 정합성이 깨지거나 문제가 생길 수도 있다. 이렇게 사용하다가 문제가 생겼을 때 파트너사를 통해 요청해서 뉴타닉스 본사 케이스를 열어 SRE의 지원을 받아야한다. 뉴타닉스 SRE가 해결하지 못하는 경우, 상위 팀으로 에스컬레이션하여 해결하고, 최종 단계에서는 개발팀까지 붙어 해결하게 된다. 하지만 기본 매뉴얼이 있어도 뉴타닉스 SUPPORT SRE가 가진 경험이나 지식, 성향에 따라 지원의 질이 달라질 수 있으며, 어떤 경우에는 기존 문제가 해결된 것처럼 보였지만, 실제로는 해결 되지 않았을 수도 있다. 또한 이것을 파트너사에서 확인하거나 문제를 수정하기는 어려운 점이 있다.

기본적으로 분산 시스템이란 특성 상 모놀리틱한 시스템에 비해 SYNC가 중요하다. 하지만 모놀리틱한 시스템의 복잡성이나 관리의 어려움과 분산 시스템의 복잡성이나 관리의 어려움을 비교했을 때 분산 시스템에서 문제가 생겼을 때 좀 더 찾기 어려운 느낌이 있었다.

내가 일해보면서 실질적으로 느낀 단점은 한번 그런 SYNC 같은 것들이 깨졌을 때 해결하기 어려운 느낌이 있었고, 어쨌든 VM 에 대한 개별적인 관리는 사용자가 별도로 해야하며, DR 등을 위한 서드파티 백업 솔루션(VEEAM 등)과의 연동이라던제 AHV가 아닌 다른 하이퍼바이저를 사용했을 때 더 그런 문제가 많았다는 느낌이 있다.

지원 같은 경우에도 CVM 위에서 올라가는 AOS는 3년, 뉴타닉스 하드웨어 같은 경우는 6년으로 그렇게 짧다고 보긴 어렵지만 길다고 보기도 어려우며, 한번 업그레이드 때를 놓치면, 중간 버전으로 업그레이드 해야하는 불상사가 생기기도 한다.

결론

어쩄거나 뉴타닉스가 가진 장점은 비교적 라이선스가 저렴하고, 노드 장애에 대해 VM 등의 서비스 장애가 비교적 적음에 있다고 보는게 맞는 것 같았다. 그래서 비교적 대규모 사이트에서 클러스터의 최소 노드가 아닌 그 이상의 많은 노드를 한꺼번에 사용했을 때 효용성이 올라간다고 생각했다. 아파치 라이선스로 된 여러 개의 오픈소스 프로그램을 변형하고 연동해서 쓰는 점에서 Nutanix community edition이 있음에도 온전한 소스가 open source는 아니라서 아쉽다고 생각했으며, 서비스 지원에 있어서도 조금 더 적극적이거나 일률적인 지원이 있었으면 하는 생각이 들었다. 아쉬운 점과 별개로 프리즘이나 LCM 등을 통한 GUI 작업과 자동화 작업을 적극 추진한다는 점에 있어서는 나쁘지 않았으나 조금 더 노드 간에 연동이 잘 되었으면 하는 바램이 있다.