가상화를 이용한 서버 통합구성에 대하여.

2020.05.14

기존 여러대의 물리서버를 하나의 물리서버로 통합하는 가상화 서버통합을 우리회사에서도 진행하고 있다.
실로 만만치 않은 작업이다.

가상화 SW는 너무 좋아진 나머지, 심지어 단종된 레거시 os를 이용하는 어플리케이션(ex. windows 2000 server..)까지
최신 하드웨어로 마이그레이션시켜서 기존에 써오던 그대로 사용이 가능하게끔 해준다.
학부생시절, 포트란인가 코볼인가 쓰는 은행들이 여전히 남아있다고 했는데.. 사실일수밖에 없구나 싶다 증말
기존에 써오던 어플리케이션을 그대로 가져오는 이유는 아무래도 뜯어고치기에 본인들도 무서운 거 아닐까? 싶다
오래된 프로그래밍 언어로 구현되어있는 것도 문제이나, 본질은 더티 코드들이 아닐까 싶다. 당시는 표준이고 디자인패턴이고 뭐고
기능만 돌아가면 땡수준으로 구현했기에.

이점만 가진 구조는 없다. 시대가 변하고 기술이 진보하면서, 통합되어있는 걸 다시 분산시키고
분산되어있는 것을 다시 통합시킨다. 어느 관점에서 보면 혁신은 새로운 기술에서 비롯된 것이 아니라, 과거의 기술을 보완시켜 현재의 문제를 해결하는 것이
혁신이라고도 생각이 된다.

무튼 가상화를 이용하여 서버 통합을 이루면, 당연히 안고가야 할 문제가 있다.
Single point of failure 와 유사하다고 해야할까 ?
여러 서버로 수행되고 있다가, 단일 서버로 뭉치니
서버 내 에러하나에 모든 가상서버들이 뻗어버릴 수 있다.

이렇기에 서버 통합시에는 신뢰성이 중요하게 여겨지는데, 여기서 신뢰성은
‘에러가 나지 않을 확률’에 가깝다기보다 ‘에러가 발생했을 때 현재 업무의 정지되는 시간을 최소화’하는 것에 가깝다.
에러 없는 유,무형의 것들이 없다. 에러는 자연발생(?)이다.
살면서 오타도 치고 하듯, 그러면서 백스페이스 누르면서 글을 계속 작성해나가듯..

서버통합 시 신뢰성을 조금 확보해 줄 세 가지 방안이 있다.
1. 클러스터링
2. SAN BOOT
3. Live migration

하나씩 간단하게 살펴보자면 ..

1. 클러스터링
단일 서버 내 여러 가상서버들을

HA구성(active-active,active-stand by..)을 뜻하는 클러스터링으로 구성해놓는 것이다.
서버그룹으로 지어놓고, 리소스 풀로 관리를 한다.
장애가 터졌을 때는 해당 서버 버리고 서버그룹 내 다른서버로 해당 업무를 수행한다.

2. SAN BOOT
어렵지 않다. 서버가 죽으면 서버에 붙어있는 fiber를 통해 san storage 에 있는 os를 구동시켜서
다른 서버로 전환하여 os를 시작 및 백업한다.

3. 라이브 마이그레이션
말그대로, 라이브 한 마이그레이션인데..
현재 단일 서버 내 올라가있는 가상서버를 라이브 상태에서 다른 물리서버로 옮겨두는 것이다.
예를들어 뭐 보안패치 등의 이유로 기존 서버를 잠시 구동중단을 해야할 때, 가상서버를 옮기는 방식이다.
라이브 마이그레이션 시 네트워크를 통해서 서버<-> 서버 간 대용량 데이터가 오고가기 때문에
라이브 마이그레이션 전용 네트워크를 구축해두는 편이 좋다.
업무용 네트워크를 쓸 순 없으니

여태까지 서버통합시 장애가 발생했을 때 신뢰성을 조금이라도 보장하기 위한 방안들을 살펴보았고,
다음은 서버통합시 보안에 대한 내용이다.

단일서버로 이루었으니, 당연히 에러뿐만아니라 보안에도 취약하다.
1. os레벨의 하드닝
2. 보안전용 어플라이언스 장비 도입..

하드닝은 모르는 포트/프로세스 다 차단해두는 것이며
어플라이언스 장비 도입함으로써, 보안패치도 직접붙어서 하지 않아도 되니 보안성+가용성을 얻어간다고 해야할까
물론 지불해야 할 건 돈이겠다.

 

마지막으로, 서버를 통합 할 시에 자주 겪는 사항인데
여러 대 서버에서 단일 가상화서버로 통합할 시에 자원구성을 어떻게 할 것이냐는 것이다.
보통은 기존 서버에서 쓰던 cpu, mem, stroage 등을 그대로 요청 및 배정받아 사용하는데.. 이게 또
환경이 달라지다보니까 자원들이 더 필요해지는 상황들이 온다.

테스트들을 통해 시스템 자원에 대해서 정확하게 파악을 해야한다.