MS-SQL 사용중입니다.
작년에 소프트웨어 예산을 편성하면서, IT 직원들과 DB에 대해서 논의를 하였습니다.
DB 라이센스는 프로세서 라이센스를 사용 중입니다.
그런데, 이러한 의견이 나왔습니다.
서버 서비스(애플리케이션) 하나에 DB 서버 하나씩 놓아야 한다는 의견을 내어 놓더군요.
DB 프로세서 라이센스가 상당히 비싸서, 하나의 DB 서버에 DB를 여러 개 놓고 사용하는 중입니다.
업데이트를 하거나 재시작 할 경우 DB 서버가 각각 나눠져 있으면 관리하기가 편하다면서 따로따로 놓자는 이야기를 합니다.
사용중인 애플리케이션이야 대부분의 회사가 보유한 ERP, 그룹웨어와 제조업체에서 사용하는 MES 등이 있고 기타 여러가지로 자산관리도 사용 중이고 한데요.
DB 서버를 스펙이 좋은 것으로 하나를 놓고 DB를 여러 개 만들어 사용하는 것이 일반적이지 않는지요?
다른 분들은 어떻게 사용하고 있는지요?
작년에 소프트웨어 예산을 편성하면서, IT 직원들과 DB에 대해서 논의를 하였습니다.
DB 라이센스는 프로세서 라이센스를 사용 중입니다.
그런데, 이러한 의견이 나왔습니다.
서버 서비스(애플리케이션) 하나에 DB 서버 하나씩 놓아야 한다는 의견을 내어 놓더군요.
DB 프로세서 라이센스가 상당히 비싸서, 하나의 DB 서버에 DB를 여러 개 놓고 사용하는 중입니다.
업데이트를 하거나 재시작 할 경우 DB 서버가 각각 나눠져 있으면 관리하기가 편하다면서 따로따로 놓자는 이야기를 합니다.
사용중인 애플리케이션이야 대부분의 회사가 보유한 ERP, 그룹웨어와 제조업체에서 사용하는 MES 등이 있고 기타 여러가지로 자산관리도 사용 중이고 한데요.
DB 서버를 스펙이 좋은 것으로 하나를 놓고 DB를 여러 개 만들어 사용하는 것이 일반적이지 않는지요?
다른 분들은 어떻게 사용하고 있는지요?
해당 질문의 문제를 해결, 도움이 되는 선택된 답변이 있습니다.
작성된 다른 답변도 확인해 보시기 바랍니다..
10개의 답변이 있습니다.
DB장애시 리스크를 최소화 하기 위한것도 있습니다.
한 솔루션이더라도 이중화해서 운영하는것도 마찬가지죠.
가상화 서버라면 코어 단위로 할당을 하지만요.
프로세스를 놔눌수 있는 방법이 없습니다.
process affinity 로 안쓰게 할수야 있지만, 그에 대한 부작용은 절대 책임 질 수 없는 결과가 올수 있습니다.
인스턴스를 여러개 설치할 수 있지만, 이게 동일 라이센스로는 되는지 잘 모르겠네요
프로세스 라이센스가 사라진지 오래라서 SQL SERVER 2008R2 이하인것 같은데
추천하진 않습니다.
: 관리의 편의성과 서비스 문제시 별도 서버/DB 구성시 운영에 좋죠
-DB 서버를 스펙이 좋은 것으로 하나를 놓고 DB를 여러개
: 장점은 라이선스 비용 절감, 그러나 장애시 전체 서비스가 문제가 되므로 위험성이 커 보입니다.
----------------------------------------------------------------------------
저희는 서버 / 스토리지 작은용량과 VMware 에센설
그리고 OS는 spla / DB는 core 단위로 구매 했습니다.
가장 좋은건 확장성/운영의 용이성입니다.
호스트 두개 구성시 Vmotion 기능이 있어 특정 Vm 장애시 다른 호스트로 넘어가는 장점도 있구요
VM별 OS/DB를 여러개로 구성과 개별 서버를 여러개 구성을 했을시
저희는 VM으로 구성을 선택했네요
정답이 없다는 댓글에 동의 드립니다.
제공하시는 IT 서비스, 제조 산업 도메인, Application / DB Server Usage 에 따라
최적의 솔루션이 달라질 듯 합니다.
팀원 분들이 IT 서비스 별로 APP/DB 서버 구성을 원하신 다면
VMware 서버 라도 하나 들이고 DB 서버 용 인스턴스를 여럿 구동 하는 것도 검토해 보시지요.
개발 단계에서 통합 DB로 개발한다면 더욱 좋겠지만, 이미 개발된 상태라면 서버 사양을 높여 가급적 동일 서버로 구동하는게 전체적인 비용 절감 및 관리에 효율적일거라 생각되네요.
MS 제품을 사용할 때는 아무래도 라이센스가 가장 큰 고민이 아닌가 싶습니다.
저희는 MS-SQL에 서비스별로 인스턴스를 생성해서 사용하고 있습니다.
굳이 물리적으로 분리해야하는 필요성이 있나 싶긴합니다.
한번 물리적으로 분리하면 앞으로도 그렇게 될 확률이 생기니, 관리자의 관리 포인트도 덩달아 많아지죠
말씀하신대로 유지보수가 용이하고 유지보수 작업이나 장애 발생시 해당 서비스에만 영향이 있기때문에 장점이 있습니다.
그런데 이런 경우에는 메인 DB는 상용DB를 사용하더라도 모든 분리된 서비스에 상용 DB 를 사용하기에는 License 비용이 어마어마하죠.
라이센스 비용을 회사에서 잘 승인해주면 그렇게 하면 되지만 한정된 프로젝트 비용으로 할 수 있는 일들을 생각해 봐야합니다.
DB 를 Express , Maria DB 이런것으로 교체 하려면 개발도 손봐야 하는데 서로서로 간간한 일이 되지 않을것 같습니다.
1. ERP
2. MES
3. 그룹웨어, 자산관리
나누는 방법론에 대해서는
DB 프로세스 라이선스가 총 몇개인지 확인하시고
프로세스수를 부하와 중요도로 갯수를 나누어 할당하시면 될것 같습니다.
예를 들어 10Core라고 하면
ERP 4Core
MES 4Core
그룹웨어, 자산관리 2Core 이런식이죠.
또한가지 방법은
1. ERP => 그대로 유지
2. MES => Standard 신규 구매
3. 그룹웨어, 자산관리 => Standard 신규 구매
이런 방식도 생각해볼수 있구요.
첫번째 방식을 하실때는
하드웨어 구매 하실때 Core당 TPMC가 높은걸로 고려하셔서 선정 하셔야 합니다.