좋습니다. 지금까지보다 SAN을 좀 더 활용하는 동시에 ESXi도 활용하고 싶습니다.
현재 단일 인클로저 EMC AX4-5 FC 스토리지 어레이에 연결된 Dell PowerEdge 1955 블레이드 어레이가 있습니다. 저는 본질적으로 SAN을 DAS로 사용하고 있습니다. SAN에 특정 물리적 시스템을 가리키는 LUN이 있고 해당 시스템은 무엇이든(대상 서버에 따라 주로 데이터베이스 및 Samba/NFS 공유) LUN을 활용합니다.
여러 개의 물리적 파일 서버가 있고 각 서버에는 적절한 공유를 제공하기 위한 삼바 구성 설정이 있습니다. RHCS가 작동하도록 한 적이 없기 때문에 파일 서버 중 하나만 한 번에 마운트된 LUN을 갖습니다. 파일 서버가 중단되는 경우 수동으로 펜싱(드라이브 마운트 해제 및 표시 해제, navisphere 유틸리티 사용 또는 DRAC를 통한 전원 차단)을 수행한 후 navisphere 유틸리티를 사용하여 다음 경쟁자에 표시된 LUN을 불러옵니다( 그런 다음 아파치와 다른 데몬을 시작하십시오). 지금 당장 손으로.
마치 Ferris Bueller가 클라리넷을 연주하는 것 같은 느낌이 듭니다. 레슨을 받은 적이 없습니다!
어쨌든 발전하려고 노력 중이에요. 내가 원하는 것은 물리적 호스트에 ESXi를 설치한 다음 두 개의 파일 서버 이미지(하나가 손상/fubar되는 경우)를 보관할 LUN을 생성하는 것입니다. 그 중 하나는 활성이고 다른 하나는 대기입니다. 적어도 이런 방식으로 자동화를 개선하지는 않지만(비록 조만간 "활성" 서버를 전환하는 스크립트를 작성하게 되겠지만) 유연성이 추가된 것 같은 느낌이 듭니다. ESXi 호스트는 다른 VM을 보유하며 하드웨어는 지금처럼 낭비되지 않습니다.
내 질문은 다음과 같습니다
1) 내 계획은 얼마나 어리석은가?
2) 실제 구현 시 LUN에 일반 vmdk 이미지를 생성해야 합니까, 아니면 "원시" 파티션을 제공해야 합니까(ESXi에서도 가능하다면)?
3) 클러스터되지 않은 파일 서버를 사용하는 "좋은" 방법이 있습니까?
답변1
당신의 계획은 미친 것이 아닙니다. 평소와 같이 달성하려는 목표와 데이터를 보호하는 방법에 따라 이를 공격하는 방법은 여러 가지가 있습니다.
먼저 "원시 장치 매핑"을 사용하여 VM에 원시 LUN을 제공할 수 있습니다. 이것을하기 위해:
- ESXi 호스트(또는 클러스터링/HA를 사용하려는 경우 호스트 그룹)에 LUN을 제공합니다.
- VM에 디스크를 추가하고 원시 장치 매핑을 선택한 다음 LUN을 가리킵니다.
- VM 내부의 SCSI 버스를 다시 검색합니다.
- fdisk, 일반 디스크처럼 fstab에 마운트하고 추가합니다.
장점: 설정이 빠르고, 사용이 빠르고, 간편하며, 나중에 V2P가 필요한 경우 디스크를 물리적 호스트에 표시할 수 있습니다.
단점: 물리적 호환성 모드를 사용하는지 가상 호환성 모드를 사용하는지에 따라 일부 VMware 기반 스냅샷/롤백 옵션이 손실될 수 있습니다.
대체 옵션은 LUN에 VMFS를 생성하여 데이터 저장소를 생성한 다음 해당 데이터 저장소에 있는 VM에 VMDK 디스크를 추가하는 것입니다.
- 장점: 사용하기 위해 라이센스를 구매하면 Storage vMotion에 친화적입니다. 이를 통해 LUN과 SAN 간에 VMDK 디스크를 핫 마이그레이션할 수 있습니다.
두 경우 모두 장애 발생 시 VMware 또는 VM이 파일 시스템을 먹어치울 경우 비슷한 위험에 처하게 됩니다. 어떤 복구 옵션을 사용할 수 있는지는 상당히 다르지만 하나가 다른 것보다 크게 낫지는 않습니다.
꼭 필요한 경우가 아니면 RDM을 배포하지 않습니다. 나는 그들이 VMDK로서 나에게 많은 유연성을 제공하지 않는다는 것을 발견했습니다.버그다른 스토리지 작업을 수행할 때 실용적이지 않게 만들었습니다(고정 이후 - 해당 링크의 RDM 섹션 참조).
VM의 경우 유연성을 위한 최선의 방법은 파일 서버의 부팅 디스크를 SAN에 VMDK로 저장하여 호스트 오류가 발생할 경우 다른 호스트에서 부팅하도록 하는 것입니다. VMware의 HA 기능을 사용하면 다른 호스트에서 VM이 자동으로 부팅됩니다(전원이 꺼진 것처럼 VM이 두 번째 호스트에서 부팅됩니다. 일반 서버의 경우처럼 일반적인 fsck 및 매직을 수행하여 이를 불러올 것으로 예상합니다). ). HA는 라이센스가 부여된 기능입니다.
VM 오류를 완화하려면 부팅에 필요한 최소한의 항목을 포함하는 파일 서버의 가벼운 복제본을 구축하고 SAMBA를 구성된 상태에서 시작하고 이를 각 호스트의 로컬 디스크에 저장한 후 다음에서 데이터 드라이브를 추가할 때까지 기다립니다. VM에 오류가 발생하고 전원을 켜세요.
SAN 장애가 발생할 경우 추가 옵션을 구매할 수도 있고 구매하지 않을 수도 있습니다. 최상의 시나리오에서는 데이터 저장소에 fsck 또는 기타 수리가 필요하지만 최소한 VM을 수정, 재구축 또는 구성할 필요는 없습니다. 최악의 경우, 데이터가 손실되어 테이프로 돌아가야 하지만... 어쨌든 이미 그 상태에 있었습니다.
답변2
나는 vmdk 이미지를 고수할 것입니다. 나중에 vmotion을 사용하게 될 경우를 대비해 예산이 책정될지 결코 알 수 없습니다.
컴퓨터가 클러스터되지 않은 경우 내가 생각하는 한 컴퓨터를 관리하는 가장 좋은 방법은 로드를 최대한 균등하게 분산시키는 것입니다. 가장 중요한 vms의 로드가 각각 최대 1/3인 비클러스터형 2950이 3개 있습니다. 이론상으로는 한 번에 두 개 이상의 상자를 풀 가능성이 없으므로 최소한 2/3는 영향을 받지 않고 계속 작동할 수 있습니다.
전력의 관점에서 볼 때 기계를 가능한 한 100% 가까이 로드하고 다른 기계의 전원을 끄는 것이 더 효율적일 수 있지만, 나에게는 모든 계란을 한 바구니에 담는 것처럼 보입니다.
나는 나 자신을 이 분야의 전문가라고 부르지 않을 것입니다. 그것이 바로 내가 하는 일입니다.
답변3
안녕 매트. 가상화 솔루션을 사용할 때 솔루션을 분할하는 방법에는 여러 가지가 있습니다. 우선, 원시 LUN(RDM)과 VMDK 성능을 보여주는 많은 벤치마크가 있었으며 그 차이는 일반적으로 무시할 수 있는 것으로 나타났습니다. RDM에 대해 알아야 할 사항: 특정 클러스터링 상황에서만 RDM(MS 클러스터링)을 사용해야 합니다. RDM에는 2TB 제한이 있지만 LVM을 사용하여 이 제한을 해결할 수 있습니다. RDM은 VMFS에 사용할 LUN을 ESXi에 제공하고 여기에 vmdk를 배치하는 것보다 추적하기가 '더 어렵습니다'. 언급한 대로 VMDK에는 svMotion, Snapshots(pRDM의 스냅샷을 생성할 수 없음) 등 몇 가지 좋은 이점이 있습니다.
무료 ESXi를 실행하는 경우 상황에 대해 다음과 같이 설명합니다. 먼저 모든 데이터는 VMFS LUN의 vmdk 파일에 있습니다. 2개의 VM을 설정하고 IP 및 서비스 장애 조치를 위해 Heartbeat를 사용합니다. Heartbeat는 서비스 IP를 이동하고 적절한 경우 데이터 LUN을 마운트 해제/마운트하는 스크립팅을 처리할 수 있습니다. 펜싱을 위해 '다운' VM의 전원이 꺼지도록 일부 VMware Remote CLI를 스크립팅할 수도 있습니다. 시스템 간 하트비트를 직접 조정하면 데이터 LUN에 액세스하거나 동일한 서비스를 실행하는 위험이 매우 낮아집니다. 여기서 핵심은 데이터 LUN의 마운트/마운트 해제와 서비스의 시작/종료가 일반 초기화 메커니즘이 아닌 Heartbeat에 의해 처리되는지 확인하는 것입니다.
대체 장애 조치는 모니터링 시스템을 통해 수행될 수 있습니다. 다운된 호스트를 감지하면 VMware Remote CLI를 사용하여 안전을 위해 전원을 끈 다음 백업 VM의 전원을 켤 수 있습니다. 이 상황에서 장애 복구는 상당히 수동적입니다.
내 "작은" 환경에서는 VMDK가 손상되는 것을 본 적이 없습니다. 또한 제가 깨달은 것은 ESX(i) 호스트가 2개 이상이거나 VM이 12개 이상이면 모든 것을 추적하는 데 도움이 되는 vCenter를 사용하고 싶을 것이라는 것입니다. Essential/Plus 패키지 중 일부는 이점을 고려할 때 비용이 많이 들지 않습니다.
답변4
"물리적 서버로 돌아갈 계획이 있나요?"라고 스스로에게 물어봐야 할 것 같습니다.
대답이 '아마도'라면 RDM을 고수해야 할 수도 있습니다. RDM이 포함된 ESXi는 광케이블이 작동하려면 무언가를 구입해야 한다고 생각합니다(esxi에서는 100% 확신할 수 없음).
RDM을 사용하여 물리적 서버에서 ESX(4.0)로 빠르게 이동한 여러 시스템이 있었습니다. 나는 Linux와 Windows 시스템을 혼합하여 사용했습니다(두 플랫폼 모두 매우 쉬움). 이전 FBSD 커널이 이를 지원하지 않기 때문에 RDM을 사용할 수 없는 물리적 서버에서 실행 중인 레거시 FreeBSD(6.0 이상)가 여전히 몇 개 있습니다. 속도가 빠르고 LUN을 지정한 다음 VMWare 도구를 설치하는 것 외에는 아무것도 수행하지 않아도 되었습니다. 두뇌가 죽었습니다.. 변환기가 없고 소란스럽지 않습니다...
스스로에게 물어봐야 할 또 다른 사항은 "VMWare의 어떤 기능을 사용하고 싶은가?"입니다.
귀하의 답변에 따라 VMDK 외에는 선택의 여지가 없을 수도 있습니다. 예를 들어 스냅샷을 위해 SAN을 사용하고 이를 위해 vmware를 사용하는 데 신경 쓰지 않는 경우..
지금까지 우리가 겪은 일에 대해 몇 가지 참고 사항을 공유하겠습니다. Vmotion은 RDM 및 VMDK와 동일하게 훌륭하게 작동하지만 Storage Vmotion은 RDM이 아닌 경우에만 올바르게 작동하며 Vmotion 스토리지를 사용하여 RDM에서 VMDK로 이동하는 것은 형편 없습니다. 그냥 변환기를 사용하세요. 대부분의 Linux 배포판에는 도구 설치가 문제가 되지 않는 오픈 소스 vmware 도구 패키지가 있습니다. 백업 어플라이언스는 정말 훌륭하게 작동하고 vmware가 없지만 우리가 원하는 만큼 많은 작업을 수행하지 않습니다. vmware 강의 수강을 적극 권장합니다. 내가 받은 것은 일주일이었고 1센트의 가치가 있었습니다. VMWare 지원은 정말 훌륭합니다. 지원 계약을 맺고 전화해야 한다면 그들은 최고입니다.. 나를 도와줄 수 있는 사람을 만나면(많은 메뉴에 대해) 좌절감을 느낍니다. ), 하지만 일단 일단 얻으면 항상 빠르고 안정적인 지원이 제공됩니다.