저를 항상 당황하게 만드는 것 중 하나는 스토리지 모범 사례입니다. 파일 시스템은 크기가 페타바이트 또는 엑사바이트에 이를 수 있다고 자랑합니다. 그러나 단일 볼륨이 수 테라바이트 이상으로 늘어나도록 기꺼이 허용하는 시스템 관리자는 많지 않습니다. 이 문제의 주된 이유는 드라이브에 장애가 발생할 경우 어레이를 재구축하는 데 시간이 얼마나 걸리기 때문이라는 것을 알고 있습니다. 단일 LUN에 드라이브가 많을수록 시간이 더 오래 걸리고 재구축이 진행되는 동안 다른 드라이브를 잃을 위험도 커집니다.
그런 다음 사용 이유가 있습니다. 관리자는 프로젝트에 할당해야 한다고 생각하는 공간의 양에 따라 LUN을 분할합니다. 나에게는 LUN이 하나의 대규모 어레이이고 할당량을 사용하는 것이 더 실용적인 것 같습니다. 이것이 모든 요구 사항(iSCSI)을 충족할 수는 없다는 것을 이해하지만 많은 NAS 시스템(NFS)이 이런 방식으로 관리되는 것을 봅니다. 또한 필요에 따라 기본 볼륨을 매우 쉽게 늘리거나 줄일 수 있다는 것도 이해하지만, 볼륨을 조작하고 가능한 데이터 손실을 방정식에 적용하는 것보다 할당량을 사용하는 것이 덜 "위험"하지 않습니까?
제가 놓친 다른 이유가 있을 수 있으니 알려주시기 바랍니다. 파일 시스템이 그렇게 클 것이라고는 기대할 수 없습니까? 재구축 시간을 줄이기 위해 하드웨어가 더 빨라지기를 기다리고 있습니까?
답변1
스핀들 분리는 하나의 큰 볼륨을 갖지 않는 좋은 이유입니다. 단일 NFS 장치에서 Exchange, SQL Server 및 기타 임의의 항목(ESXi 게스트)을 실행하는 경우 스핀들 분리가 필요할 것입니다. Exchange 데이터와 Long은 SQL 데이터베이스와 로그뿐만 아니라 서로 별도의 스핀들에 있어야 합니다.
답변2
드라이브를 재구축하는 것은 파일 시스템이 아니라 드라이브 자체에 의존합니다. 2TB 드라이브를 사용한 경우 재구축하는 데 많은 시간이 필요합니다.
재구축은 raid 5의 문제입니다. 이제 컨트롤러가 raid 6을 지원할 수도 있고 훨씬 더 나은 성능을 위해 raid 10을 만들 수도 있습니다(최고의 성능을 원한다면). LUN 내보내기는 SAN의 작업이고, 파일 시스템 내보내기는 NAS의 작업입니다.
둘 다 장단점이 있습니다(구글에서 검색해 보면 관련 자료가 많이 있습니다). 독립적인 LUN(또는 파일 시스템)을 많이 만들면 스냅샷 백업의 장점이 있습니다.
답변3
개인적으로 저는 iSCSI 또는 NFS를 통해 실제 엔터프라이즈 트래픽(Oracle, MSSQL, 프로덕션 ESX)을 전혀 실행하지 않을 것입니다. 저는 일반적인 성능과 장애 상황 모두에서 FC를 알고 신뢰합니다. 아, 물론 이는 대규모 LUN을 생성하고 세분화할 수 없으며 상당한 복잡성/작업이 발생하지만 시스템 가용성과 최종 사용자 경험 수치가 우리가 기대했던 것보다 더 좋고 일관성이 있다는 것을 의미합니다.
귀하의 실제 답변에 관해서는 귀하의 게시물이 매우 NetApp/파일러 지향적인 것으로 보이므로 마지막 단락입니다. 그러나 귀하가 직접 이유를 설명했습니다. 디스크 인터페이스는 디스크 용량보다 크게 뒤처졌습니다. 즉, 특히 기존 트래픽을 재구축하는 동안 적절한 성능을 확인하려는 경우 재구축 시간이 터무니없을 수 있다는 의미입니다. 디스크는 항상 죽기 때문에 단순히 관리자의 삶을 더 쉽게 만들기 위해 재구축 중에 여러 플랫폼 성능에 영향을 미치려는 아이디어는 실제로 수명이 짧은 방법입니다. 또한 순전히 플랫폼 보안 관점에서 볼 때 시스템을 분할하려고 할 수 있으며 '큰 LUN' 접근 방식은 해당 시나리오에서 작동하지 않을 수 있습니다(물론 하드웨어 기반).
궁극적으로 Enterprise SAN은 본질적으로 비즈니스 또는 미션 크리티컬하며 비용에 대한 가용성과 일관성, 관리 용이성 또는 최고의 성능을 요구합니다.