XSLAB V-Raptor SQ ARM 서버 사용기

시작하기

아마도 2016년쯤이었나, 정말 오랫만에 한국에 방문했었다. 내 기억이 맞다면 거의 5년 만에 한국에 방문하는 것이었으며 4주 휴가내서 3주를 한국에 머무르다 하와이 돌아와서 1주 쉬고 출근했던 기억이 난다. 비록 온라인 상이었지만 나름대로는 우분투 한국 커뮤니티의 활동을 꽤 오랫동안 해오고 있었는데, 그러다가 만났던 여러 사람들 중 당시 활발하게 활동하던 유명환이라는 분을 알게 되었고 한국으로 휴가를 갔을 때 인사도 드릴겸 이 형님의 회사에 방문했다가 개발 중인 제품에 대해 소개를 받게 되었다. 처음엔 그냥 “아 나한테 영업을 하시는구나” 정도로 생각하고 흘려들었는데, 계속 듣다보니 조금 흥미로운 부분이 생겼다. 결국 이 회사의 제품인 V-Raptor SQ ARM 서버 (브이랩터)를 도입하게 됐으나 배경 스토리는 단순하지 않았다. 우선, 배경 썰을 풀어본다.

배경 이야기

내가 근무하는 곳은 하와이 주립 대학교 사범대학College of Education, University of Hawaii으로, 현재 시스템 어드민 혹은 시스템 관리자 (Systems Administrator)라는 직책으로 근무하지만 하와이 주립대학교에서 근무하는 모든 컴퓨터 관련 인력의 공식 직책은 IT전문가IT Specialist라는 이름 하나만 존재한다. 따라서, 시스템 어드민이라는 직책은 편의상 우리끼리 지어서 부르는 셈이나 다름없다. 미국 내 다른 주립대학교의 구조는 잘 모르므로 우리 학교로 설명을 하자면, 학교의 중앙 부서에서 전체적인 통제를 하되 각 단과대학들이 개별적으로 운영하는 식으로 되어있다. 따라서, 인력의 이동은 사실상 없다고 봐야하며, 이동이 있다면 그건 퇴사하고 새로 입사하는 것과 다름 없다고 봐야한다. 다시 말하자면, 사범대학에서 일하던 직원이 다음 달부터 중앙 전산실에서 일한다고 한다면, 그건 사범대학에 사표를 내고 주립대학교 중앙전산실로 다시 입사를 하는 것이란 얘기다 (그래서 송별회도 한다). 따라서 예산도 각 단과대학들이 별도로 운영하며 전산 시스템 역시 각자 운영한다. 그렇다보니, 주립 대학교 내 다른 대학 (단과대학)들은 어떤 서버를 얼마나 갖고있는지, 어떤 식으로 운영하는지 등에 대한 정보가 전혀 없는 셈이다. 우리 학교 (사범대학)은 총 400 여명의 교직원이 대략 3개 정도의 건물에서 근무하며, 한 명당 1대씩만 잡아도 업무용으로 최소 400대의 컴퓨터가 캠퍼스 내부에서 운영되고 있다고 볼 수 있다. 하와이 주립대학교의 단과대학이 10개가 넘으니, 주립대학교 전체로 보면 학생 제외하고 교직원만 4만명이 넘는 큰 규모의 학교이지만 운영은 각자 따로 하다보니 소분화가 가능하지 않나 싶다.

내 사수였던 사람이 오픈스택 쪽에서 유명한 회사인 미란티스Mirantis로 스카웃 제의를 받아서 이직한 뒤 (나중에 우분투Ubuntu 제작사인 캐노니컬Canonical로 옮겨가서 주요 요직에 앉았고, 현재 NVIDIA에 시니어 디렉터로 근무하고 있다), 학교에서는 내 사수 자리에 해당하는 사람을 새로 뽑지 않고 공석으로 두기로 결정하여 내가 모든 것을 책임지게 되었다. 그리고 내 사수였던 사람이 나에게, 아니 우리 학교에게 남기고 간 것은 오픈스택 클라우드openStack Cloud였다. 그리고 이게 모두에게 생각보다 큰 짐이 됐다.

사범대학이 비록 교직원 400 여명 규모의 단과 대학이고 IT와는 거리가 먼 교육계이지만 나름대로는 IT 분야에 꽤 많은 예산을 투입하고 있는 학교다. 대학 내에 교육공학Educational Technology이라는 분야가 있는데, IT 분야를 교육과 접목시켜 교수법을 발전시키는 연구분야가 있어서 IT에 관심있는 교수진들이 좀 있고, 결정적으로 내 부서장이 컴공 학사를 졸업하고 CCNA 자격증이 있는 교육학 박사Ed.D이다보니 왜 IT 쪽으로 투자를 해야하는지 너무나도 잘 이해하는 분이었다. 심지어, 오픈소스 정신을 좋아하며 남들 다 쓰는 맥북도 안쓰고 (애플을 정말 싫어한다) 심지어 윈도우 컴퓨터도 쓰지않고 오로지 우분투만 고집해서 쓸 정도로 오픈소스 매니아이기도 한 우리 부서장은, 가끔 학생들 가르칠 때 사범대학 내에 오픈소스 수업을 따로 개설해서 할 정도였다 (사실 오픈소스는 교육계에서 봤을 때 저소득층 자녀들을 위한 평등한 기회 접근 측면에서 굉장히 좋다). 따라서 우리 부서의 기본적인 방침이라고 할 수 있는 것은, 교직원들에게 IT를 이용하여 좋은 질의 서비스를 제공하는 것이 직원들의 업무능률향상이나 교수들의 수업/학생 관리에 더 큰 도움이 된다고 생각하는 것이다. 그렇다보니, 예전 사수가 도입한 오픈스택으로 인해 우리 학교에서는 내부적으로 대략 100 여개가 넘는 크고작은 웹서버가 운영되어오고 있다.

오픈스택이라던가 도커Docker라던가 하는 가상화 개념이 도입되기 전에는 정말 원시적인 운영을 해왔었는데, 즉 아파치 버츄얼호스트 Apache Virtual Host로 한 서버에서 꼭 필요한 웹사이트를 여러 개 운영하는 식으로 최소한의 웹서버만 운영해왔다가, 사수였던 사람이 미란티스의 오픈스택 도입 후엔 단 몇 대의 서버로 수백 개의 가상머신을 개발자들이 몇 번의 클릭으로 생성할 수 있게 되면서 당시엔 신세계가 열렸었다. 물론 VMware ESXi라는 것이 예전부터 있었고 잘 알고있었지만 단과대학 입장에선 가격이 비싸서 아예 도입할 생각조차 안하고 있었다. 오픈스택은 소프트웨어 자체는 오픈소스이므로 당연히 무료이며 미란티스로부터 기술지원만 돈을 내고 사용했었다.

그럼에도 불구하고 이 오픈스택은 나와, 날 도와주는 2명의 프로그래머에게는 상당한 짐이 되었다. 이 2명의 프로그래머는 서버 관리가 아닌 집중해야할 본인들의 프로그래밍 업무가 따로 있었으며, 오픈스택이라는 소프트웨어는 두어명으로 운영되는게 사실상 무리이기 때문에 문제가 생길 때마다 미란티스 고객지원에 의존해야했었고, Compute 노드 하나라도 문제 생기는 날에는 그 노드에서 돌아가는 모든 웹사이트가 죽어버리니 정말 난리였었다. 게다가 주립대학교 데이터 보관 규정상 모든 데이터는 반드시 캠퍼스 내에서 관리해야한다는 조항 때문에 오픈스택을 내 사무실에서 운영했었는데, 학교 건물이 상당히 노후되다보니 전력이 불안정해서 전기공사도 종종 했고 그것 때문에 오픈스택 전체를 셧다운 시켜야하는 일도 한 두번이 아니었다. 오픈스택 운영해본 사람은 알겠지만, 수백대의 가상머신이 돌아가는 수십대의 오픈스택 노드를 셧다운 시킨다는 건 정말 상상하기 싫은 일이다. 그걸 1년에 2번 3번 겪게되다보니 오픈스택 더 이상 안쓰고 싶다는 생각이 들더라. 우여곡절 끝에, 오픈스택 서버들을 중앙전산실 데이터센터DataCenter로 이전하여 운영하였으나, 미란티스 사의 정책 변경으로 말도 안되는 액수를 고객지원비로 요구하여 결국 오픈스택을 포기하고 중앙 전산실에서 유료로 제공하는 VMware ESXi를 사용하게 되었다.

이후에도 계속해서 학교 건물의 전기 공사는 간헐적으로 있어왔고, 그때마다 매번 사무실 내 서버들을 셧다운 시켜야 했었다. 중앙전산실의 VMware는 별도의 데이터센터에서 운영되니 이것들을 제외하더라도, 10G 스위치, 방화벽, 인프라스트럭쳐 서버, VPN, 백업 서버, Nextcloud 등 여전히 열 몇대의 서버가 운영되고 있었는데, 모두 셧다운 시켰다가 다시 키고 하는 과정은 역시나 여간 부담이 아니었다. 서버 운영하시는 분들은 다 아시겠지만, 서버를 재부팅하고나면 돌아오지 않는 서버들이 종종 있다. 그러다보니, 정전시 UPS에서 제공되는 전력이 몇분이나 지속되는지, 우리가 갖고있는 서버가 필요한 전력을 정전 중인 시간만큼 공급해줄 수 있는지를 신경쓰게 되었고, 그러다보니 만약 서버가 전기를 적게 먹으면 정전이 발생해도 문제가 없을 것 같다는 생각이 들었다. 그리하여 한국을 갔다오고나서 몇 개월 정도 지나자 유명환 형님의 회사 제품인 V-Raptor SQ ARM 서버라는 물건에 관심이 생기기 시작했다.

이 서버는 우리가 사용하는 스마트폰의 CPU를 사용하는데, 스마트폰의 CPU가 세간의 인식과는 달리 산업용으로 따로 나오는 모델이 있어서 수명이 굉장히 길고, 산업용으로 쓰이기 때문에 상당히 안정적이라고 하였다. 게다가 스마트폰에도 쓰이니만큼 적은 전력을 소모하는데, 스마트폰에 들어가는 CPU와는 다르게 24코어나 되는 고성능 저전력이었다. 그외에도 여러가지 장점들인 OpenBMC이니 페이스북이 주도하는 Open Computer Project이니 하는 것들이 있었으나 사실 별로 와닿지 않았었다. 그 이유는, 일단 내가 근무하는 곳이 그런 대규모 서버를 관리하는 곳이 아니다보니 그런 것의 장점을 체감할 수 없었고 필요도 없었으며, 내가 중점적으로 보는 것은 500명 정도 규모의 인원에게 안정적인 서비스를 지속적으로 제공할 수 있어야한다는 점이었다. ARM이 전기를 적게 쓰는 것 역시 큰 장점이어서 이것을 눈여겨 보게 됐지만, 전기세를 절약할 수 있다는 점이 장점이 된 것이 아니라, 위에서 언급한 UPS에서 공급해야하는 전력량이 줄어든다는 점이 장점이 되어서 눈여겨 보게 됐다.

내가 알고있는 스마트폰의 CPU는 그냥 RISC 기반 CPU라는 것이 전부였고, 인텔의 성공으로 인해 RISC는 결국 지는 해가 되어 거의 사장되어가다가 스마트폰의 등장으로 인해 살아난 정도로 인식하고 있었다. 스마트폰이 게임도 돌리고 고성능 앱도 돌리는 것을 보긴 했지만 어찌됐든 결국은 모바일 기기용 이라는 인식이 지배적이었는데, 이 ARM이라는 CPU에서 오픈스택으로 가상머신을 쾌적한 속도로 돌리는 것을 보고 약간은 충격을 받았다. 이 산업용 서버용 ARM 프로세서는 내가 아는 그런 수준의, 스마트폰이나 라즈베리파이에 들어가는 CPU가 아니었다.

도입

이 형님과 회사 직원 한 분이 동행하여 우리 학교까지 오셨고 직접 시연을 보여주심으로써 성능을 확인할 수 있게 됐고, 또한 전기 사용량을 낮춰야한다는 나의 의견을 새로 바뀐 내 사수와 부서장이 잘 받아들여주어, 비록 기대에는 못미쳤지만 2019년 1월에 딱 5대만 도입해보기로 결정했었다. V-Raptor SQ 서버에는 ARM 노드가 총 32대가 장착 가능한데 딱 5대만 구입하기로 해서 제품 시연을 위해 하와이까지 방문하신 형님한테는 좀 죄송한 생각이 들기도 했었다. 당시 형님에게는 말씀드릴 수 없었던 내용도 있었는데, 당시 부서장이 나한테 “굳이 우리가 어떤 제품의 베타 테스터가 되고싶진 않다”라는 얘기를 했었기 때문에 학교 직원인 나로서는 당연히 학교의 입장에서 고려해야만 했었다. 게다가 하와이 사는 지인들 중 IT 직종에 있는 분들에게 조언을 구해보니, 굳이 검증되지 않는 제품을 사서 그것도 교직원들에게 제공되는 실제 서비스용 서버Production server로 모험을 할 필요는 없지않나 라는 게 대부분의 의견이었다. 어찌됐건, 날 믿어주는 사수 덕분에 도입 요청은 승인됐고 겨우 5대를 도입함에도 불구하고 형님과 직원 한 분이 직접 하와이까지 오셔서 설치까지 모두 다 진행하였다.

인프라스트럭쳐 서비스

가장 우선적으로 V-Raptor에서 운영하기로 결정한 프로그램은 인프라스트럭쳐 서비스였다. 즉, DHCP, DNS와 더불어서 가장 중요한 OpenLDAP을 오래된 레노보 인텔 서버Lenovo Intel Server에서 V-Raptor로 옮겨오기로 했다. 하와이 주립대학에서는 사용자의 계정과 패스워드 등은 반드시 중앙 전산실의 LDAP을 연동해서 써야하며, 따로 지정해서 만드는 아이디 패스워드 등은 사용하지 않도록 되어있다. 따라서, 내부적으로든 외부적으로든 모든 교직원 및 학생들은 중앙전산실의 LDAP으로 SSO (Single-Sign-On)을 구축해서 써야하므로 LDAP은 사실상 단과대학 내에서 가장 중요한 기반 서비스Infrastructure Service라고 볼 수 있다. 이것을 매우 안정적이라고 하는 산업용 ARM 프로세서 위에서 운영해보기로 결정하였고, V-Raptor에서 공식적으로 지원하는 우분투 18.04에 올렸다. 2019년도 당시에는 거의 모든 리눅스 배포판이 ARM을 적극적으로 지원하기 시작한 시기라서 거의 대부분의 잘 알려진 리눅스 배포판 및 패키지들은 ARM 용으로 이미 나와있어서 문제가 없었다.

2대의 ARM 노드에 OpenLDAP을 멀티마스터로 구성하여 1번 노드를 Primary로 설정하여 거의 대부분의 LDAP과 DNS 요청을 1번 노드에서 처리하게 했고, 단과대학 내 10개 정도의 각 부서별 VLAN을 위한 DHCP는 2번 노드에 구성하였다. 예전 사수였던 사람이 LDAP을 굉장히 좋아해서 DHCP도 LDAP과 연동되어있는데, 아무래도 LDAP 요청을 받는 서버에 DHCP를 운영하는 게 낫겠다는 판단이 들어 2번 노드에 VLAN용 DHCP를 구성했다. V-Raptor SQ에서는 각 노드당 하나의 이더넷 포트만 제공하는데, DHCP 서버라면 당연히 2대의 이더넷 포트로 운영하는게 맞는 구성이겠으나, 그냥 하나의 포트에 전부 설정하여 지금까지 400일이 넘는 시간 동안 1번 2번 노드 모두 재부팅 한 번 없이 LDAP, DNS, DHCP를 운영해오고 있다. 노드에 장착된 ARM CPU 하나당 24개의 코어, 16기가 램, 256기가 SSD가 장착되어있으며, LDAP, DNS, DHCP를 운영하는 2개의 노드에 대한 로드는 다음과 같다.

몇 주 정도 지켜보면서 잘 돌아가는 것이 확인되었고, 그래도 부하를 좀 분산시켜보고자 중앙전산실에 있는 VMware ESXi에서 돌아가는 100 여대의 웹서버들의 인증용 LDAP 서버용도로 그쪽에다 하나 운영하기로 했다. 즉, 사범대학 내의 네트워크에서 들어오는 요청은 V-Raptor의 LDAP에서 처리하고, VMware의 웹서버들이 요청하는 LDAP은 그쪽에서 자체적으로 처리하는 식으로 하기로 했다. 그래서 V-Raptor의 멀티마스터는 그대로 두고 VMware의 LDAP은 V-Raptor의 LDAP 데이터를 실시간 복제Replication하는 식으로 하여 읽기전용Read-Only으로 구성했다.

처음엔 잘 작동했는데 시간이 얼마 지나지 않아서 VMware에서 돌아가는 LDAP 서버의 LDAP 데이터베이스 전체가 망가지는 현상이 계속해서 발생했다. 계속해서 조사해보니, LDAP 데이터베이스를 복원하고 레플리케이션을 설정하고나면 한동안은 잘 작동하는 것처럼 보였지만, 멀티마스터 즉 V-Raptor에서 돌아가는 LDAP 서버에서 데이터의 변화가 생길 경우 VMware의 LDAP 데이터베이스 내용 전체가 날아갔다.

이것을 계속해서 조사해볼 인력은 나 밖에 없는데, 그렇다고 이것만 계속해서 알아보면서 시간을 쓸 수는 없는지라 결국 그냥 VMware의 LDAP 서버는 운영하지 않기로 하고, 모든 LDAP 트래픽을 V-Raptor가 받는 것으로 변경했다. 아마도 내 추측으로는 V-Raptor는 ARM CPU이고 VMware 서버는 인텔 CPU인데, 아무래도 ARM에서 운영되는 LDAP 서버에서 나오는 바이너리 데이터가 인텔 서버에서 돌아가는 서버에서는 이해할 수 없는 데이터라서 이런 일이 생기는 게 아닌가 싶었다.

VPN

그렇다면 이제 남은 3대를 활용할 차례였다. 우리 대학에서는 그동안 VPN으로 OpenVPN의 상용 버전인 OpenVPN Access Server, 일명 OpenVPN-AS라는 것을 사용해오고 있었다. LDAP 지원이 잘된다는 점이 가장 큰 이유였고, 상용버전은 관리용 웹인터페이스가 꽤 잘 되어있어서 관리측면에서 장점도 있는데다, 상용 라이센스의 가격이 저렴해서 정말 오랜기간 동안 써오고 있었다. 다만 문제는, OpenVPN 측에서 상용버전 패키지는 ARM 플랫폼을 지원하지 않는데다 앞으로도 지원할 생각이 없다고 고객지원센터에서 답변하여 어쩔 수 없이 인텔 서버를 계속해서 유지하고 있었다. 그러다가 어느 날 OpenVPN의 라이센스를 재계약해야하는 시기가 다가왔는데, OpenVPN 측에서 라이센스 정책을 변경하면서 가격을 과도하게 인상하였고 이에 큰 반발심을 가진 오픈소스 매니아인 우리 부서장이 거부감을 느껴 다른 VPN 대체제를 찾아보기로 했다.

사실 개인적으로 OpenVPN 라이센스를 비싸더라도 갱신했으면 했었다. 일단 무엇보다도 OpenVPN-AS의 관리용 웹인터페이스가 꽤 괜찮았으며, 200 여명이 넘는 인원의 컴퓨터에 OpenVPN 클라이언트를 설치하고 사용해오면서 문제가 거의 발생한 적이 없었는데다, OpenVPN-AS 서버 또한 매우 안정적이고 유지보수도 쉬워서 재부팅조차 필요없이 꽤 오랜 시간을 문제 없이 써왔기 때문이었다.

막상 대체제를 찾아보려니 정말 쓸만한 VPN이 없었다. 물론, 당연히 쓸만한 VPN은 많지만, 대학에서 어떤 기반 소프트웨어를 도입할 때는 정말 고민해야할 것이 많다. 그중 가장 핵심적인 요소는, 해당 소프트웨어를 사용하는 유저는 아예 컴맹으로 간주해야한다는 점이었는데, 이공계도 아닌 교육계 교수진 특히나 고연령대의 교수 및 직원들은 컴퓨터의 사용법이 우리가 생각하는 상상 이상으로 기상천외하고 예측할 수 없는 방향으로 흘러가기도 한다. 게다가, 특별한 사용법을 익혀야하는 소프트웨어들은 따로 스케쥴을 잡고 교직원들 모아놓고 여기에 스케쥴이 안맞는 사람까지 생각해서 몇 주에 걸쳐 트레이닝 세션까지 해야하기 때문에, 단순히 소프트웨어를 도입하는 데에서 끝나는 게 아니라 다른 직원들이 교육까지 시켜줘야하니 그런 점까지 모두 고려해야했다. 게다가 교육이 끝나고나서도 뭔가 접속이 안된다거나 하는 문제가 생길 때 헬프데스크에서 교직원들 컴퓨터를 점검까지 해줘야하니 부가적으로 생기는 업무량은 짐작하기 어려울 정도다. 따라서, 소프트웨어의 사용법은 매우 쉽고 간단해야하며, 뭔가 입력해야하는 것이 극도로 적어야한다. OpenVPN은 그런 목적에 매우 충실하게 맞는 소프트웨어로서, 사용자 컴퓨터에서 클라이언트를 한 번만 설치하고나면 아이디와 패스워드 입력 외엔 아무 것도 해야할 것이 없었다. 나머지는 서버 측에서 관리자가 제어하기만 하면 되기 때문에 컴맹도 사용하는데 전혀 문제가 없었다.

그러나, 다른 VPN 대체제들은 거의 대부분이 컴퓨터를 잘 쓸 줄 아는 사람들을 기준으로 설명되어있고, 상용 버전의 경우 금액이 OpenVPN과 별반 다를 게 없었으며, VPN 대체제라는게 딱히 많지도 않았다. 그리하여 여러가지 심사숙고 끝에 결정한 것이 일본의 한 박사학위 대학원생이자 동 대학의 교수가 된 사람이 프로젝트로 만들어 나중에 오픈소스로 전환한 SoftEther VPN이라는 VPN을 선택하여 테스트에 들어갔다.

2020년 테스트 할 당시에는 ARM용 패키지가 있다고 되어있었으나, 실제로 설치를 하고 실행을 했을 때는 정상적으로 로그인이 되지 않았다. 정말 오랜 시간동안 조사하고 구글링을 해봤으나, L2TP over IPsec을 RADIUS를 거쳐 인증하는 과정 중간에서 무슨 이유로 인해 인증이 되지 않거나, 프로토콜을 인식할 수 없거나 하는 문제가 생겼었다. 그리하여 포기하고 인텔 서버에서 운영을 하다가 2021년에 업그레이드 된 버전으로 다시 테스트 해보니 정상적으로 작동이 되었다. 그래서 3번 노드에 설치하여 혼자 개인적으로 오랫동안 테스트를 해오고 충분히 잘 된다고 판단하여 VPN 서비스 또한 V-Raptor로 옮겨왔다. 아래는 대략 20 여명 정도의 사용자가 접속하여 아침 시간에 잠시 큰 트래픽을 발생시켰을 때 캡쳐한 트래픽 상황이었다.

위의 스크린샷에 나온 시간인 오전 9시부터 오후 2시까지의 로드가 대략 13에서 15 정도 되었으며, 일부 유저들이 네트워크 속도가 매우 느리다는 얘기를 했었는데, 기가빗 이더넷 포트에서 저 정도 트래픽에다 24코어에 로드 13-15면 그렇게 큰 부하는 아니라고 생각했음에도 매우 느리다고 얘기를 했을 정도이니 뭔가 문제는 있을 것 같았다. 물론 로드가 24가 넘어야만 느려지는 게 정상이라고 생각하는 건 아니지만, 그래도 평균 속도 17 Mbit/s에 CPU 로드 13-15 정도면 CPU는 24개의 코어 중 반 정도 밖에 안쓴 셈이고, 네트워크 트래픽 17 Mbit/s 역시 기가비트 이더넷 성능의 2%도 안썼다고 봐도 되는데도 매우 느리다고 하여, 앞으로도 좀 지켜봐야할 것 같다.

4번 노드는 위의 SoftEther VPN을 관리하는 웹인터페이스를 직접 만들어서 현재는 아파치 서버 하나만 운영 중이며, 5번 노드는 SoftEther VPN의 Failover, 즉 비상용 VPN 서버와 RADIUS를 올려뒀다.

마무리

피크시간대의 5대의 전력소모량은 다음과 같다.

400일이 넘는 업타임에도 불구하고 안정적으로 잘 돌아가고 있는 인프라스트럭쳐 노드 및 안정적인 VPN 운영으로 인해 제품에 신뢰가 갔으며, 게다가 서버 5대의 전력 소모가 인텔 서버 1대나 2대에 해당하는 겨우 100w에 불과하다는 점이 상당히 매력적이었다. 이번에 노후된 서버 8대를 폐기처분하면서 V-Raptor 노드PEC를 5대 추가 구매하기로 하였다. 현재로서는 웹서비스의 상당수가 VMware에서 운영되므로 V-Raptor에서 당장 필요한 서비스는 없어서 조만간 계획을 세울 예정이다. 현재 캠퍼스 내 건물에 부착된 RFID 기반 도어락 시스템이 MS-SQL을 사용하고 있으나, 아쉽게도 현재 마이크로소프트는 MS-SQL을 공식적으로 인텔 서버만 지원해주므로 당분간은 인텔 서버를 유지해야하며, 백업용 스토리지 서버와 Nextcloud 서버는 대용량 하드디스크가 장착되는 스토리지 서버가 필요하므로 MS-SQL을 이들 서버에 올려 같이 운영하고 있다. 따라서, 노후된 서버 8대를 전부 폐기처분 완료하고 나면, 이후에는 백업 스토리지, Nextcloud를 제외하면 V-Raptor SQ만 남는 셈이다. 현재 서버 시장이 ARM에 매우 호의적이므로 앞으로 ARM에 대한 지원은 지금보다 더 나아질 것으로 기대된다.

다만 한 가지 문제가 되는 것은, LDAP 멀티마스터 서버 뿐만 아니라 DNS와 DHCP까지 전부 V-Raptor SQ 하나의 서버에서만 돌아가므로 이 서버가 멈추면 인프라스트럭쳐 전체가 사용불능 상태가 된다는 점이었다. 그렇다고 V-Raptor SQ 서버를 하나 더 도입할 수는 없으므로, V-Raptor SQ의 BMC를 업그레이드는 커녕 재부팅도 겁나서 못하고 있다. V-Raptor SQ는 BMC가 일반 리눅스 운영체제로 만들어진 하나의 컴퓨터와 같은데, 현재로서는 이 BMC가 멈추면 V-Raptor SQ 서버 내 모든 노드PEC가 멈추게 된다. 멀티마스터로 구성된 LDAP이나 DNS 같은 노드들은 서로 번갈아가면서 재부팅할 순 있지만, BMC 자체를 재부팅하는 일은 아예 있을 수 없는 일이 되어버린 것이다.

일반적으로 전산시스템의 점검을 위해 사용자에게 전체 메일을 보내 사전에 미리 공지하고 점검하는 일은 어디서나 흔히 있는 일이지만, 학교라는 특성상 교직원들이 밤낮을 가리지 않고 접속하는 일이 매우 흔하고, 전산실의 규모가 큰 곳이 아니다보니 나 혼자서 해야하는 업무 특성상 밤이나 새벽에 이런 일을 진행하는 경우도 아예 없다. 내가 밤이나 새벽에 일을 하고 다음날 쉬면, 다음날 문제가 터졌을 때 내 일을 해줄 사람이 없다. 큰 회사라면 직원들이 서로 번갈아가면서 교대근무를 하기 때문에 가능하지만, 난 교대를 해줄 사람이 없기 때문이다. 결국은 전체 서비스가 다운되어야만하는 작업은 평일 아침이나 낮에 하게 되는데, 평일 아침과 낮 시간에 학생들을 상대로 수업을 하는 교수 입장이나 사무를 봐야하는 직원들 입장에서 봤을 때, 아예 수업 진행을 못하거나 일을 못하는 상황이 생긴다고 공지를 해야한다는 것이었다. 그리고 당연히도 이런 경우에는 항의하는 교수나 직원들이 많다. 그래서 이런 일은 아예 진행할 수 없고, 더군다나 모든 서비스가 중단된다는 작업이니만큼 스케쥴 조정하기가 매우 어려워서 결국 BMC 모듈의 uptime이 500일 가까이 되어가는 상황이 생기고 있다. 차기 버전은 이 문제가 개선됐다고 하니, BMC를 재부팅하는 문제는 좀 나아질 것 같다.

앞으로 정전이나 전기공사로 인한 전기차단 발생시 V-Raptor로 인해 덜 수 있는 스트레스 및 적은 전기사용량이 나를 비롯한 많은 이들에게 도움이 되었음 좋겠다.