우리는 두 개의 클러스터를 설정하고 있습니다. 하나의 개발과 하나의 프로덕션. 프로덕션에서는 OLTP와 DW라는 두 개의 SQL 인스턴스를 호스팅합니다.
개발에서는 4개의 OLTP 비프로덕션 환경과 하나 이상의 DW 비프로덕션을 호스팅합니다. 우리는 더 많은 DW 비프로덕션과 더 많은 OLTP 시스템을 확보하기 위해 노력하고 있습니다.
나는 PROJ가 프로젝트 이름의 3개 이니셜이 되는 이와 같은 명명 체계를 고려하고 있습니다.
개발 클러스터
- MSSQLPROJD1\D1(개발자)
- MSSQLPROJD2\D2(테스트)
- MSSQLPROJD3\D3(QA)
- MSSQLPROJD4\D4(단계)
- MSSQLPROJD5\D5(DW)
Prd 클러스터
- MSSQLPROJP1\P1(PRD)
- MSSQLPROJP2\P2(DW)
슬래시 왼쪽의 각 이름은 네트워크 전체에서 고유해야 합니다. 각 서버에서 슬래시 오른쪽의 인스턴스 이름은 고유해야 합니다.
이것에 대한 생각이 있나요? 프로젝트가 진행됨에 따라 인스턴스 이름이 현실에서 벗어나는 것을 방지하려고 노력하고 있습니다. 예를 들어 특정 환경이라고 부르는 것을 변경하거나 용도를 변경하고 싶다고 가정해 보겠습니다. 그런 다음 인스턴스의 목적 목록을 업데이트하고 작업을 완료할 수 있습니다.
이와 같은 계획이 당신에게 어떻게 효과가 있었습니까? 어쩌면 당신의 가게에서는 다른 방식으로 일을 할 수도 있습니다. 그것에 대해 말해 주세요.
감사해요.
개정판 2
개발 클러스터
- SQLERPD1\D1(개발자)
- SQLERPD2\D2(테스트)
- SQLERPD3\D3(QA)
- SQLERPD4\D4(단계)
- SQLERPD10\D10(DWDev)
- SQLERPD11\D11(DWTest)*
Prd 클러스터
- SQLERPP1\P1(PRD)
- SQLERPP10\P10(DW)
*원했지만 현재로서는 사양이 지정되지 않았습니다.
답변1
사람들이 사용하는 명명 표준은 수백만 가지가 있습니다. 사용하는 표준이 장기적으로 환경에 적합하다면 실제로 사용하기에 옳고 그른 것은 없습니다. 가장 나쁜 일은 명명 규칙을 선택한 후 명명 규칙을 변경하는 것입니다.
고려해야 할 사항은 다른 Dev 클러스터 또는 다른 prod 클러스터를 추가하는 경우 이 규칙이 어떻게 작동하는지입니다. 계속해서 잘 확장될까요?
개인적으로 나는 이와 같은 명명 규칙을 사용하는 것을 좋아합니다. 필요에 따라 사이트 이름 등을 사용하여 필요에 따라 쉽게 수정할 수 있습니다.
실제 머신:
SQL01A
SQL01B
Windows 클러스터 이름:
SQL01
SQL 가상 이름:
SQL01V01
SQL01V02\INST1
SQL01V02\INST2
이렇게 하면 서버에 로그온하지 않고도 가상 이름이 속한 실제 시스템을 쉽고 빠르게 확인할 수 있습니다. 그리고 아래에 표시된 것과 같이 다른 클러스터를 추가하면 확장이 잘됩니다. 더 많은 클러스터를 쉽게 추가할 수 있으며, 상황을 복잡하게 만들지 않고도 모든 클러스터에 더 많은 인스턴스를 추가할 수 있습니다.
실제 머신:
SQL02A
SQL02B
Windows 클러스터 이름:
SQL02
SQL 가상 이름:
SQL02V01
SQL02V02\INST1
SQL02V02\INST2