데이터베이스 클러스터링 얼마나 사용하나요?
글쓴이: jam02 / 작성시간: 목, 2008/12/18 - 4:30오후
요즘 데이터베이스 클러스터에 대해 관심있게 살펴보는데...
실제로 얼마나 사용할까 궁금해졌습니다.
DBMS 회사들이 cluster 기능들을 제공하는데,
실제로 많이 사용하나요?
사용하면 어느 정도 규모의 사이트에서 어떤 용도로 사용하는가요?
제가 아는 용도는 고가용성(High Availability)나 확장성?(Scalability)을 위해 사용하는 것 같은데..
가용성이 우선인지.. 확장성이 우선인지..
TPC-C 벤치마크 결과를 보니 탑랭킹의 구성에서 막상 클러스터를 사용하지 않는 것을 보니
성능이 주목적은 아닌 것 같다는 생각이 듭니다.
대표적으로 오라클의 RAC를 많이 들어본 것 같고,
올해 Sybase에서도 비스무리한 것을 발표한 것 같은데
실제 써 보신 분이 계신지 궁금합니다.
그리고 MySQL에서도 cluster기능을 제공하는데 이것도 써 보신 분 계신가요?
좀 어리적은 질문이고... 벤더마다 많이 다를 것도 같은데.
궁금하고 막상 알길이 없어 질문합니다.
그냥 관련 경험이 있으신 분들 자신의 경험에 비추어 말씀해주세요.^^
이런 저런것을 물어보았는데..
결론은 .. 실제로 사용하는가?입니다. 벤더에 관계없이...
Forums:
대부분(?)은 오라클RAC
대부분(?)은 오라클RAC 또는 오라클10G를 도입해서 클러스터링 형태로 사용하고 있다고 보면 맞습니다.
왜냐... 영업을 할때, 그렇게 안파는 경우가 없기 때문이죠.
--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러
--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러
이유가
이유가 인상적이네요. ^^
감사합니다.ㅎ
MySQL cluster 퍼포먼스....
요즘은 안해봤습니다만....
몇년 전에 testbed로 시험해 보았습니다. 3대 가지고 테스트 했었는데요.
일단 InnoDB나 MyISAM에 비해 성능이 많이 떨어집니다. (자세한 건 KLDP Wiki를 참조하세요. 문서 잘 만들어 놓으셨던데)
그리고, 아키텍처상 가용 메모리 사이즈가 역시 중요하죠.
당시에 되지도 않는 메모리(1G)를 꼽고 4G가 넘는 데이터베이스를 insert 했는데요.
죽진 않지만, 결국 오류가 나면서 작업을 할 수 없었습니다.
그래서 데이터베이스 사이즈를 좀 줄여서 시험해 보았습니다만
제가 만족할 만한 결과가 나오질 않아서 그냥 replication으로 선회했던 기억이 있네요.
지금은 어떨른지 모르겠습니다.
---------------------------------
There's always another way, dear.
---------------------------------
There's always another way, dear.
많이 씁니다.
저 같은 경우는 주로 공공기관을 많이 다녔는데 많이들 사용합니다.
주로 차세대 시스템을 도입한다든지 시스템을 개편할 때 등, 뭔가 더 나은 모습으로 변신할때
이러한 클러스터링 구조를 많이 채택합니다.
"어떠한 장애가 발생해도 서비스가 가능하다" 이런 식이죠.
어떤 기관은 비슷한 다른 기관이 도입하면 이에 질세라.. 우리도 도입해야 한다..
이런 식으로 도입하는 경우도 있습니다.
개인적인 생각으로는 HA가 물론 중요하긴 하지만 RAC처럼 거의 실시간으로 서비스가 이어져야 할 만큼
중요한 서비스가 얼마나 될까요?
좀 오버라는 생각도 있습니다.
.
MySQL 클러스터링이나 Sequoia를 이용한 클러스터링을 테스트해 본 적이 있습니다. High Scalability를 얻기는 어려운 거 같더군요. 이쪽 클러스터링의 주목적은 HA 인 거 같습니다.
오라클 RAC는 접해보지 못해서 모르겠네요
클러스터링은 관리측면에서도 편리하지요..
클러스터링은 관리측면에서도 편리하지요..
한대 놓아두고 다른 한대에서 작업을 하면 되니깐.
시스템 관리 관점에서도 중요한 부분이지요.
예전 오라클 9i에서 RAC 구축작업을 한 적이 있었지요.
뭐 바람직한건 아니라고 할 수 있겠지만 (아주 크리티컬하지는 않았어가지구..) 낮에 업무중에 한대 DBMS내리고 작업해도 되니 좋긴 하더군요.
그리고 질문하신 것은 가용성, 성능 등 무엇을 할 것이냐에 따라 구성하는 방식이 달라질 수 있겠지요. 일반적으로 클러스터링이라고 한다면 가용성이 더 큰 목적일 것이구요.
오라클 RAC 방식은 성능을 위해서 추가로 계속 노드를 늘리면 되도록 구성하는 것이지요.
개인적으로는 DBMS의 성능은 클러스터링을 통한 것도 있지만 DB 쿼리 튜닝 등 개발쪽에서 잘 하는 것이 더 중요하지 않나 생각합니다.
---------------------------
문태준
http://groups.google.co.kr/group/sysadminstudy 시스템어드민 공부모임
http://tunelinux.pe.kr
http://database.sarang.net
---------------------------
문태준
http://groups.google.co.kr/group/sysadminstudy 시스템어드민 공부모임
http://tunelinux.pe.kr
http://database.sarang.net
오라클은 좀 쓸모있다?
답변 감사합니다.
오라클 클러스터를 주로 사용하는 것 같네요...
답글로는 MySQL은 거의 쓸모없는 수준인 것 같고..
오라클은 대략 심리적인 안도와 더불어 관리가 용이하다는 정도로 요약되나요?
사실 다른 벤더 MS나 IBM의 경우가 궁금한데..
경험이 있으신분이 계신가요? ^^
저번에 썼는데 안
저번에 썼는데 안 올라간 모양이군요.
MSSQL은 MS클러스터서버와 함께 주로 사용됩니다. 주변에서 본바로 MS클러스터는 고가용성 클러스터로 Active-Standby 형태로 대부분 구축해서 사용하는 듯 합니다.
IBM은 아시다시피 DB2를 전폭적으로 밀어붙이고 있는데, DB2는 애초부터 Cluster DB라고 광고해서 팔리던거죠. n개의 클러스터에서 성능이 linear하게 올라간다고 하던데, IBM은 주로 Mainframe에서 DB2를 제안하더군요.
요약하자면
MSSQL - MS Cluster - Active/Standby 구조
Oracle - Oracle RAC or 10g - Active/Active 구조 (3노드 이상 구축한데를 못봤음...)
IBM DB2 - 클러스터링 DB - n개의 노드에서 Active/Active 구조 (메인프레임으로 한데만 봤음)
주로 저렇게 구현되더군요.
--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러
--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러
postgresql slony 는
postgresql slony 는 master/slave 형식이라 백업용 노드를 설정한다던지, select 전용 노드를 만들때는 좋습니다만, multi-master 가 아니라는 큰 단점이 있습니다. 혹시, 어떤형태로든, postgresql 의 multi-master 솔루션 사용해 보신분 계시나요?
삽질의 대마왕...
삽질의 대마왕...
postgresql..
postresql에 slony라는 replication도 있었군요.. ^^
postgresql slony 는
postgresql slony 는 master/slave 형식이라 백업용 노드를 설정한다던지, select 전용 노드를 만들때는 좋습니다만, multi-master 가 아니라는 큰 단점이 있습니다. 혹시, 어떤형태로든, postgresql 의 multi-master 솔루션 사용해 보신분 계시나요?
삽질의 대마왕...
삽질의 대마왕...
규모가변성이랑
규모가변성(scalability)과 성능(performance)은 다른 문제라는…
그렇죠...
performance와 scalability는 다르게 쓰이는데...
성능이라고 쓴 건 잘못된 표현인 것 같네요.
꼭 변명을 하자면..
그냥 뭉꿍그려서 성능이라고 말하기도 합니다..ㅎㅎ
예를 들어 동시 접속자가 늘어나면서 성능이 떨어졌다라고 말할 수 있지 않나요?
암튼. 적절한 지적인것 같아..확장성?이라고 고쳤습니다.
제가 여기서 말하는 건 동시접속자 수 혹은
저장되는 데이터 크기에 대한 확장성(!)을
의미하는 것입니다.
혹시 클러스터 사용해보신적 있으면
관련된 의견 부탁드립니다.
오라클 10g 3대를
오라클 10g 3대를 연결해서 ERP소프트웨어(꽤유명한거라고만 해두죠)의 DB의 Scability를 잰문서가 있는데, 문서는 못드리겠고, 대략 결과만 말씀드리죠.
일단 1대의 DB서버에서 8Core를 사용하여 측정한 수치를 100으로 두고 다음과 같습니다.
8코어 1노드 - 100
8코어 2노드 - 18?
8코어 3노드 - 26?
이번에는 1대의 DB서버에서 16코어를 사용하여서 측정한 자료입니다.
16코어 1노드 - 21?
16코어 2노드 - 38?
이번에는 32코어를 사용하여 측정한 수치입니다.
32코어 1노드 - 36?
32코어 3노드 - 115?
이자료를 갖고서 가로세로 매트릭스를 만들면 성능향상 수치가 나오겠지요? (끝자리는 누가 알아볼까봐 물음표를 달았으니 알아서 생각하세요)
통상 노드수를 늘이는 것을 수평확장성(horizontal scability)라고 부르고, 단일노드에서 CPU수를 늘이는 것을 수직확장성(vertical cability)라고 부릅니다.
숫자를 잘 보시면, 8코어 2대를 두는 것보다는 16코어 한대를 쓰는 것이 성능이 훨씬 좋습니다. 따라서 성능이 이슈가 된다면 일단 한 노드에서 CPU를 최대한 늘이고, 그 후에 수평으로 노드를 늘여서 성능과 안정성을 동시에 확보하는 것이 DB 클러스터 설계의 방법이라고 보시면 됩니다.
--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러
--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러
음 그건 예상된 결과 아닌가요?
일반적으로 8코어 두 대보다 16코어 한 대가 훨씬 비쌀 텐데...... -.-
전혀 그렇지는
전혀 그렇지는 않죠.
8코어 두대를 연결하기 위해서 중간에 설치해야할 Switch 및 공유스토리지 비용까지 고려한다면 16코어 한대가 훨씬 쌀수 있죠.
그리고, 16코어 한대에 RAC없이 오라클을 사는게 더 싸죠.
--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러
--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러
재미있는 결과네요..
재미있는 결과네요..
어떤 테스트인지는 모르지만..
일단 16코어에서 2배 이상의 성능이 나오는 것도 매우 신기하고...
최근 16코어 이상에서 성능문제가 지적되는 글들을 본 적이 있는데..
위의 실험에서도 16코어에서 32코어로 가는 경우는
상대적으로(CPU당으로 보면) 성능이 떨어지는군요..
보신 자료는 공개된 자료는 아닌가보군요..
저도 한번 보고 싶은데..
보안상 문제만 없다면 보내주실 수 있나요? ^^
혹시 오픈소스
혹시 오픈소스 병렬디비라고 하는 scimoreDB 써보신분은 안계신가요?
그리고 이런 병렬 디비용 벤치마크 프로그램이 뭐 있던데 이거 써보신분은 또 안계신지요?
내 혼에 불을 놓아 ..
덕분에
저는 써본 건 당연히 없고.. 처음 들어보네요..
덕분에 키워드 검색해서 봤는데..
사용하는 곳도 라이코스 독일?이랑 덴마크 무슨 사이트가 있고..
유럽에서 개발된 DBMS인 모양이네요..
갑자기 세상이 넓구나 하는 생각이 듭니다... ㅎㅎ
상화에 맞게 쓴다면..
오라클9i RAC 3node 와 Mysql NDB Cluster 를 직접 설치,관리,서비스 했었습니다.
NDB Cluster 에서 성능이 안좋다는 말이 종종 나오는데, 어떤 근거에 의한건지 잘 모르겠습니다.
AMD64 cpu, memory 8G, linux 64bit 버전으로 Replication 으로 master 1node, slave 2node 에서 slave에 동기화
지연 문제로 NDB Cluster(4node,64bit)를 구축해서 사용했을 시 성능은 대만족 이였습니다.
문제는 mysql 재시동시 메모리에 데이터를 올리는 시간이 좀 걸렸다는거 빼고는 성능상의 문제는 없었습니다.
노드간 인터커넥터
좋은 답변 감사드립니다.
koseph님이 사용하실 때와 버전이 달라 기능이 개선된건지..
구성하신 환경이 다를 수도 있고.. 원래 액세스 패턴이 다를 수도 있어서..
원인을 유추하긴 어렵지만..
어쨋든.. MySQL Cluster로 replication에서 발생하는 문제를
해결하셨다는 경험이시니..
MySQL Cluster에 대한 잘못된 편견은 버려야 겠군요. ^^
잠깐 궁금한게 더 있는데..
MySQL Cluster 구성하실때 노드간 인터커넥터는 무얼 쓰셨나요?
그냥 이더넷으로 구성하신건가요? 아님
인피니밴드 같은 별도의 고속네트워크를 이용하셨나요?
좀 더 구체적으로 알려주시면 도움이....
사용하셨던 MySQL 버전이나 정확한 배포판의 종류 정도만 알려 주셔도 많은 도움이 될 것 같습니다. ^^
replication 동기화 지연 문제로 고생하신 걸 clustering으로 해결하셨다고 하셨는데 업데이트가 무지하게 많이 일어나는 서버였나 봅니다.
데이터베이스가 엄청나게 큰 경우(수Gb짜리)에도 혹시 시험해 보셨는지 모르겠습니다.
공개 가능하시면 부탁드립니다.
---------------------------------
There's always another way, dear.
---------------------------------
There's always another way, dear.