예전에 Active StandBy 이중화에 대해서 질문을 드렸던 적이 있습니다..
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
< 과거 질문 내용 >
엑티브 스탠바이 이중화 관련해서 질문드립니다.
서버 1 - App, DB 구성
서버 2 - App, DB 구성
위의 서버 1,2 처럼 두 개의 서버를 엑티브-스탠바이 형태로 데이터는 실시간으로 동기화 되는 형식으로
이중화를 구현하고 싶은데 힘든 방법일까요..?
App서버 따로, DB서버 따로 서버를 구성해서 이중화를 구성하거나
L4를 도입하거나 하면 좋겠지만 추가로 장비를 구입해야되서.. 좋은 방안 부탁드립니다..
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
최근에 위와 같은 질문을 드렸던 적이 있습니다.
현재 위와 같은 상황에서, 저희 회사 내의 L4를 통해 이중화는 가능할 것 같습니다.
그런데 어플리케이션 부분은 L4를 통해서 쉽게 이중화를 구성해 Failover가 가능하다고 하지만,
DB 이중화는 L4로 만족 못하는(?) 것으로 알고 있습니다. 그런데 추가로 알게 된 내용이 있는데 Virtual IP를 구성하여 이중화가 기술적으로 가능할까요..? 참고로 DB는 오픈소스 DB(마리아DB 등.)를 사용할 예정입니다.
추가로 말씀드리자면, 저희 회사에서 어떤 솔루션을 구축하기로 했는데 솔루션 업체에서 권장사항으로 서버 구성을 액티브, 스탠바이 형식으로 서버 두대와 개발서버 1대를 권해서, 권한대로 총 서버 3대를 도입하기로 했습니다.
솔루션 업체에서는 보통 이 솔루션을 구축하는데 이렇게 한 서버에 ap과 DB를 구성해 active standby 형태로 서버를 도입하여 이중화를 구성하고 솔루션을 구축했다고 합니다. 이 대화를 나누는 중에 그때 VIP를 통한 이중화 구현도 가능하다고 하는데 어떻게 구성을 했는지 상세히 말해주지는 않더라구요..
지금 처음 프로젝트를 맡아서 하는 건데 시간은 급박하고 이제 1년된 운영자인데 여러모로 따질 것이 많아 걱정입니다.
위에 쓴 글을 보면 너무 중구난방식으로 나열한거 같지만, 늦게 퇴근하고 집가는 길에 질문을 드리네요..
좋은 답변 부탁드립니다..
6개의 답변이 있습니다.
active-standby 이중화 구성에 기본적으로 가상 IP를 사용할거라 생각되고요.
액티브-스탠바이 형태의 이중화는 동일한 환경으로 구성된 두개 서버를 마련해 두고 한대 서버는 실제 서비스를 수행하고있고(액티브), 다른 한대는 업무에 필요한 서비스를 내려 두고서 액티브 역할을 수행하고 있는 서버가 정상 구동을 하고 있는지를 계속적으로 점검하고 있다가 일정 시간동안 액티브 서버로 부터 정상 구동하고 있다는 응답을 받지 못할 경우나 액티브 서버로 부터 오류가 있다는 응답을 받을 경우에 액티브 서버에게 스탠바이로 전환하라는 메시지를 보내고, 내려 두고 있던 서비스들을 올려서 자신이 액티브 역할을 하는 형태로 구동되게 되고요.
클라이언트들이 서버에 접속할때 이중화 서버에 할당된 가상 IP를 통해서 접속하게 되기 때문에 클라이언트들은 1번 서버가 액티브인지, 2번 서버가 액티브인지 따질 필요 없이 지정된 IP (가상 IP)로만 접속하면 되는 것이고요.
서버에서는 액티브 역할을 하고 있는 서버가 가상 IP를 가지고 있으면 되는 것이겠죠.
액티브에서 스탠바이로 전환할때 구동시키고 있던 서비스들을 내리면서 가상 IP를 제거하면 될 것이고, 스탠바이에서 액티브로 전환할때는 내리고 있던 서비스들을 올리면서 가상 IP를 넣어서 서비스를 하면 되는 것이고요.
두 서버간에 서로 정보를 주고 받기 위해 ( Heart beat check ) 서버 두대간의 전용 LAN 케이블을 연결해서 구성하는게 일반적이고요.
액티브-스탠바이 구성에서 디스크 미러링을 하냐, 하지 않냐 하는 것은 스토리지를 어떻게 이용하냐에 따른 문제가 되겠고 미러링 구성을 하냐 하지 않냐에 따라 이중화 비용 및 성능, 안전성 등에도 영향을 미치게 되겠고요.
성능 및 안정성을 위해 디스크 미러링을 하지 않는 스토리지 공유 방식으로 이중화를 구성하는걸 권장하고 싶고요.
참고로 덧붙이면...
많은 분들이 OSI 7 계층에 대한 이해가 부족한 것으로 보이는데요.
네트워크에서
l1이라는 건 전기적인 신호에 대한 영역이라 할 수 있고, 아날로그 전압이 몇 볼트냐에 따라 0이냐 1이냐 등에 대한 물리적인 신호를 처리하는 다양한 규정(Protocol)들을 정해둔 계층이 되겠고요.
l2는 물리 계층과 논리 계층이 만나는 지점으로 Mac Address 를 기반으로 서로 정보를 주보 받는 프로토콜이 정의되어 있는 계층이 되겠고요. 허브가 l2 기반에서 작동되는 장비가 되겠고요.
l3는 IP 주소를 기반으로한 프로토콜이 정의되어 있는 계층이 되겠습니다. 가상 IP도 IP 주소 관련된 내용이기 때문에 l3 영역에 대한 내용이 되겠고요. 라우터가 l3 기반에서 작동되는 장비가 되겠고요.
l4는 포트 주소를 기반으로 한 프로토콜이 정의되어 있는 계층이 되겠습니다. 포트 기반의 정책 설정을 하는 방화벽은 l4 기반으로 차단 정책을 설정한다고 보면 되겠죠. 물론 방화벽이 ip를 이용해서 차단 설정을 하기 때문에 l3 기반으로 작동하기도 하고요.
l5는 연결을 유지 시키고 끊고 하는 규약들이 정의 되어 있다고 보면 될 것 같고요.
l6는 데이터를 암호화 시키거나 코드화, 변환 등에 대한 약속들이 정의되어 있는 계층이라고 보면 되겠고요.
최 상위 계층인 l7은 사용자와 인터페이스 하는 애플리케이션에 대한 내용들이 정의되어진 계층이라 보면 되겠네요.
엄격하게 각계층을 구분해서 장비를 만들거나 개발을 하지는 않지만 기본적인 개념은 OSI 7 계층 기본 정의에 기반한다고 보시면 될것 같네요.
wansoo | 4년 이상 전
엑티브 스탠바이 HA 이중화 구성(vIP 포함)은 각 솔루션 마다 구현하는 방법이 다르기 때문에 각 솔루션마다 구성도 다릅니다. (대체로 개념은 비슷)
DB+APP을 1서버에 넣고 엑티브 스탠바이 구성은 가능 합니다.
업체가 대답을 잘 못하는것은 실제로 그 업체가 구축하는것이 아니라 다른 업체에게 위탁 하려는것 같습니다.
L4 스위치는 로드밸런싱 및 이중화 기능을 웹서버(데이터 동기화가 필요 없기 때문에)에 사용 하기 적합하지만, DB서버에는 사용 할 수 없습니다. (L4가 데이터 동기화를 해주지 않기 때문에)
따라서, DB서버는 데이터 동기화를 완벽히 해주는(데이터 손실 없는) HA 솔루션을 사용 해야 합니다.
서포터 | 4년 이상 전
현재 저희 전산실 외부 서비스 구축 내용입니다.
1) WEB서버 2대와 L4 스위치 1대 구성
L4에 매니지먼트 IP 와 WEB쪽 VIP 설정 그리고 health check : http ( TCP 80) 설정하였습니다.
서비스 : Apache , Tomcat
2) DB 서버 2대 와 HA 구성
DB : MariaDB , HA Sloution : 00 제품
이중화 : VIP , IP binding , HA 스크립트
그리고 가장 중요한거 개발 Test 서버 2대 ( 기존 남은서버 활용)
외부 서비스 목적에 따라 구성 방식이 다를듯 합니다.
web/was , DB를 분리하는게 기본적으로 맞을듯 합니다.
일반적으로 vip라고 하면 L4 ip를 의미 합니다.
디비서버 같은 경우는 vip만 가지고 이중화를 할 수는 없구요.
RAC 등의 추가적인 설정이 칠요 합니다.
디비 이중화는 여러가지가 있는데요.
데이터의 무결성을 보장해줄 수 있느냐 없느냐의 차이가 있다고 보시면 됩니다.
양성환 | 4년 이상 전
Master 디비가 VIP를 가지고 슬래이브로 동기화하다가 MHA가 주체르리변경하는방식입니다.
어플리케이션과 같이 디비를 쓰는구조는 중요서버라면 사용하지않는것이좋습니다
gIoop | 4년 이상 전
문의 내용은 현실적으로 어려운 부분입니다.
우선 어플리케이션의 2중화는 리소스의 사용량이 늘었는데 스케일 업을 하는 개념이
액티브-패시브 방식을 의미 할 수 있지만 이러한 부분은 온프레미스 장비에서는 불가능합니다.
그럼 가능한 방법은 로드밸런싱이라는 방법의 부하분산인데 이런 경우는 어플리케이션이 2대가 다 켜져 있는 방법이고 여러가지 방법이 있습니다.
어플리케이션의 로드밸런싱은 보통L2, L3,L4 , L7으로 서비스를 놔눌 수 있는데
L4 의 장비를 이용하면 로드밸런싱이라고 해서 부하를 분산 시켜주는 역할을 할 수 있구요.
이런 경우는 둘다 켜져있고 접속이나 사용을 놔눠주는 역할을 하죠
L2면 브릿지나 허브 L3면 L2+라우팅 L4면 TCP,UDP 스위칭이나 VIP 이용한 부하분산
L7이면 IP와 포트분리등으로 접근 가능할 것 같네요
디비는 종류에 따라 적은대로 Active-Passive 방식도 가능하고 Read Only Replica 도 가능 합니다.
디비 종류에 따라 제약 사항이 있습니다.
장비가 더 필요할 수 도 있고, 라이센스가 추가로 필요할 수도 있고, 기술적인 구현이 더 필요할 수 있습니다.
다만 위에서 어플리케이션과 디비가 같이 있는 상태에서 Active 와 Passive node가 함께 구성이 되어 있는 상태에 디비가 한쪽이 문제가 생겨서 전환이 된다?
그렇다면 어플리케이션도 정상이 아닐 수 있습니다.
=========================================================
열심히 적고 나서 질문 보니, L4가 있다고 하니 어플리케이션은 문제가 없겠네요 ㅜ.ㅜ
적은내용이 아까워서 지우지는 않고 내용을 조금 더 합니다.
오픈소스 DB 인 Maria 도 Mysql 의 형태에서 처럼 read Replica 및 failover 를 지원합니다.
다만 어플리케이션과 같이 있는 서버라면 VIP 로 구축은 문제가 없지만,
동일서버에서 그러한 형태로 구축은 위험부담이 더 크다고 생각이 듭니다.
여튼 3가지 방법 ( 4가지지만 1개는 aws 에서 가능해서 언급하지 않습니다. )
Sequencial => Failover 와 가장 하며 접속을 순차적 시도합니다. (read replica 불가)
loadbalancer => Failover 와 유사하며 접속을 랜덤 시도합니다. (read replica 불가)
replication => read Replica 가능
gIoop | 4년 이상 전
양성환 | 4년 이상 전