느린 OS 드라이브, 빠른 데이터 드라이브

수년간 사람들이 운영 체제 파티션에는 고성능, 고신뢰성 데이터 스토리지를 선택하지만 중요한 데이터 저장소에는 느리고 “비용 효율적인” 스토리지를 선택하는 경향이 있다는 것을 발견했습니다. 이런 현상이 얼마나 자주 발생하는지 놀랍습니다. 이제 하이퍼바이저의 등장으로 같은 동작이 거기서도 반복되는 것을 보고 있습니다 – 기존에 존재하던 문제를 더욱 복잡하게 만들고 있습니다.

오늘날 많은 시스템에서 우리는 시스템의 모든 구성 요소가 공유하는 단일 스토리지 어레이만을 다룹니다. 이런 경우에는 스토리지 시스템 성능 불균형 문제에 직면하지 않습니다. 이것이 이 접근 방식의 큰 장점 중 하나이며 강력히 권장되는 주요 이유입니다. 모든 성능이 공유 풀에 있으며 성능이 필요한 구성 요소가 그에 접근할 수 있습니다.

성능이나 신뢰성 설계를 향상시키려는 시도에서 또는 기술적 필요에 의해, 많은 경우에 사람들이 스토리지 어레이를 분리하여 하이퍼바이저와 운영 체제를 하나의 어레이에, 데이터를 다른 것에 배치하는 것을 발견합니다. 하지만 제가 충격적이라고 생각하는 것은 하이퍼바이저나 운영 체제 전용 어레이가 종종 용량이 엄청나게 크고 성능이 극도로 높다는 것입니다 – 종종 15,000 RPM 스핀들이나 심지어 솔리드 스테이트 드라이브까지 큰 비용을 들여 사용합니다. 거의 항상 RAID 1으로 구성됩니다(1998년의 일반적인 표준에 따라).

여기서 이해해야 할 것은 운영 체제 자체가 사실상 스토리지 IO 요구 사항이 없다는 것입니다. 주로 시스템 로깅을 위한 소량이 있지만, 그것이 필요한 전부입니다. 운영 체제 파티션은 거의 완전히 정적입니다. 필요한 구성 요소는 주로 부팅 시 메모리에 로드되며 다시 접근되지 않습니다. 로깅이 필요한 경우에도 많은 경우 이 로그는 중앙 로깅 시스템으로 전송되고 시스템 스토리지 영역으로는 전송되지 않아 그 필요성을 줄이거나 제거합니다.

하이퍼바이저의 경우 이 효과는 훨씬 더 극단적입니다. 하이퍼바이저는 기존 운영 체제보다 훨씬 가볍고 덜 강력하기 때문에 임베디드 시스템처럼 동작하며, 실제로 많은 경우에 임베디드 시스템입니다. 하이퍼바이저는 시스템 부팅 시 메모리에 로드되며 때때로 로깅을 위한 경우를 제외하고는 시스템이 실행 중인 동안 미디어가 거의 필요하지 않습니다. 하이퍼바이저는 물리적 크기가 작기 때문에 총 크기가 매우 작아 느린 미디어에서도 전체 하이퍼바이저를 스토리지에서 완전히 읽는 데 필요한 총 시간이 매우 짧습니다.

이러한 이유로 스토리지 성능은 운영 체제, 특히 하이퍼바이저에게는 거의 또는 전혀 중요하지 않습니다. 빠른 스토리지와 느린 스토리지의 차이는 실제로 시스템 부팅 시간에만 영향을 미치며, 1초와 30초의 차이가 거의 눈에 띄지 않을 것입니다. 자동화된 일상적인 시스템 재시작 중 계획된 유지 관리 창에서 주로 주 1회 최대로 발생하거나, 긴급 상황에서만 시스템이 오프라인 상태가 되는 매우 드문 경우, 때로는 몇 년에 한 번씩 발생하는 시스템 시작 중 추가 몇 초를 언제 인지하겠습니까? 가장 느린 스토리지 시스템도 이 역할에는 필요 이상으로 훨씬 빠릅니다.

느린 스토리지도 일반적으로 시스템 로깅 활동에 필요한 것보다 많은 배나 빠릅니다. 로깅이 매우 집중적인 드문 경우에는 이 문제를 해결하는 많은 방법이 있습니다. 가장 명백하고 일반적인 솔루션은 운영 체제나 하이퍼바이저가 사용하는 드라이브 어레이가 아닌 다른 드라이브 어레이로 로그를 보내는 것입니다. 이것은 매우 쉬운 솔루션이며 필요한 경우 실제로 매우 실용적입니다. 다른 일반적이고 매우 유용한 솔루션은 로컬 장치에 로그를 전혀 보관하지 않고 Splunk, Loggly 또는 ELK와 같은 원격 로그 수집 유틸리티로 전송하는 것입니다.

대부분의 사람들이 운영 체제와 하이퍼바이저에 대해 가장 큰 우려를 가지는 다른 주요 사항은 신뢰성입니다. 종종 교체 불가능한 데이터보다 시스템의 비교적 중요하지 않은 측면을 보호하는 데 더 많은 노력을 기울이는 것이 일반적입니다. 그러나 운영 체제와 하이퍼바이저는 필요할 때 새로 설치와 수동 재구성으로 처음부터 쉽게 재구축할 수 있습니다. 손실될 수 있는 세부 사항은 일반적으로 다시 만들기가 비교적 간단합니다.

물론 이것이 이러한 시스템 파일 시스템이 백업되지 않아야 한다는 것을 의미하지는 않습니다. 물론 대부분의 경우 백업되어야 합니다. 하지만 백업도 실패하는 경우를 위해서, OS 파티션이나 파일 시스템의 손실이 진정한 재앙보다는 불편함에 불과한 경우가 드뭅니다. “데이터” 파일 시스템이 별도인 한 거의 모든 경우에 원본 데이터에 접근하지 않고도 복구하는 방법이 있습니다. 그리고 운영 체제와 하이퍼바이저의 특성상 변경이 드물기 때문에 백업은 일반적으로 덜 자주 해도 됩니다. 업데이트가 적용될 때만 수동으로 트리거될 수도 있습니다!

DevOps 및 클라우드 컴퓨팅 공간의 많은 현대 시스템에서 운영 체제와 하이퍼바이저 파일 시스템을 시스템 이미지나 구성 관리 시스템에 의해 원격으로 정의되기 때문에 완전히 일회용으로 보는 것이 매우 일반적이 되었습니다. 점점 더 일반적이 되고 있는 이러한 경우에는 전체 시스템이 거의 즉시 특별한 상호 작용 없이 재생성되도록 설계되었기 때문에 데이터 보호나 백업이 필요 없습니다. 시스템은 완전히 자기 복제합니다. 이는 시스템 파일 시스템 보호의 필요성을 더욱 사소하게 만듭니다.

성능에 대한 필요성의 부재와 재생성을 통해 주로 처리되는 보호 및 신뢰성에 대한 필요성의 부재를 함께 고려하면, 우리가 가진 것은 우리가 일반적으로 가정하는 것과는 매우 다른 요구를 가진 시스템 파일 시스템입니다. 이것이 스토리지에 대해 무모해야 한다는 것을 의미하지는 않습니다. 여전히 시스템이 실행 중인 동안 스토리지 고장을 피하고 싶으며 불필요하게 재구축하는 것은 재앙이 되지 않더라도 시간과 자원의 낭비입니다. 따라서 신중한 균형을 유지하는 것이 중요합니다.

물론, 이러한 이유로 운영 체제나 하이퍼바이저를 데이터와 동일한 스토리지 어레이에 포함시키는 것이 이제 일반적인 관행이 되었습니다 – 시스템 파일에 접근하는 것과 데이터 파일에 접근하는 것 사이에 거의 또는 전혀 필요한 스토리지 접근이 없기 때문에 OS에 빠른 부팅 시간을 제공하고 시스템이 온라인 상태가 되면 데이터 접근 시간에 부정적인 영향을 주지 않는 큰 시너지 효과를 얻을 수 있습니다. 이것이 오늘날 시스템 설계자들이 스토리지의 효율적인 사용 필요를 해결하는 주요 방법입니다.

운영 체제나 하이퍼바이저를 데이터를 보유한 어레이에서 분리해야 할 때 – 여전히 다양한 이유로 발생할 수 있는 경우 – 우리는 일반적으로 낮은 비용으로 합리적인 신뢰성을 확보하려 합니다. 기존 스토리지(로컬 디스크)를 사용할 때 이는 운영 체제 스토리지에 소형, 저속, 저비용 회전 드라이브를 사용하는 것을 의미하며 일반적으로 간단한 RAID 1 구성으로 됩니다. 실제 사례로는 가능한 가장 작은 크기의 5400 RPM “친환경” SATA 드라이브 사용이 있습니다. 이것들은 전력을 적게 소비하고 구매 비용이 매우 낮습니다. SSD와 고속 SAS 드라이브는 무관한 보호와 완전히 낭비되는 성능에 대한 프리미엄 비용이 들기 때문에 피할 것입니다.

덜 전통적인 스토리지에서는 여러 시스템의 낮은 우선순위 스토리지를 복제되지 않은 공유 느린 어레이에 통합하는 저비용, 고밀도 SAN을 사용하는 것이 일반적입니다. 이것은 추가 아키텍처 설계를 정당화할 수 있고 스토리지 통합 과정에서 필요한 비용 절감을 만들기에 충분한 밀도를 달성할 수 있는 더 큰 환경에서만 효과적입니다. 하지만 더 큰 환경에서는 이것이 비교적 쉽습니다. SAN 부트 장치는 비용 절감을 위해 많은 서버에서 매우 낮은 비용 어레이를 활용할 수 있습니다. 가상 공간에서 이는 OS 가상 디스크에 사용되는 저성능 데이터스토어와 데이터 가상 디스크에 사용되는 또 다른 고성능 풀을 의미할 수 있습니다. 이것은 부트 SAN 전략과 동일한 효과를 가지지만 더 현대적인 설정에서 가능하며 이를 달성하기 위해 내부적으로 SAN 아키텍처를 쉽게 활용할 수 있습니다.

마지막으로, 가장 극적으로, 하이퍼바이저와 함께 일반적인 경험 법칙은 성능과 신뢰성 요구 사항이 기존 운영 체제보다 훨씬 낮기 때문에 기존 스토리지 대신 SD 카드나 USB 드라이브에 설치하는 것입니다. 일반적으로 이런 종류의 드라이브가 시스템이 실행 중인 동안 고장나더라도 시스템이 처음 부팅된 후에는 드라이브를 사용하지 않기 때문에 실제로 아무 문제 없이 계속 실행될 것입니다. 재부팅 시에만 문제가 발견될 것이며, 그 시점에 보조 SD 카드나 USB 스틱과 같은 백업 부트 장치를 사용할 수 있습니다. 이것은 VMware vSphere의 공식 권고 사항이며 Microsoft 담당자들이 HyperV에 대해 종종 권고하고 HyperV의 OEM 벤더들을 통해 공식적으로 지원되며 Xen, XenServer 및 KVM 시스템에 대해서도 종종 권고되지만 그렇게 광범위하게 지원되지는 않습니다. 하이퍼바이저 스토리지에 SD 카드나 USB 드라이브를 사용하면 가상화 서버가 임베디드 시스템으로 효과적으로 전환됩니다. 이것이 서버에 기존 디스크를 필수품으로 생각하는 데 익숙한 시스템 관리자들에게 부자연스럽게 느껴질 수 있지만, 라우터와 스위치와 같은 엔터프라이즈급, 매우 중요한 시스템들이 수십 년 동안 지속되며 정확히 같은 이유로 같은 전략을 사용한다는 것을 기억하는 것이 중요합니다.

SD 카드나 USB 드라이브를 사용하는 이 임베디드 스타일 모드의 하이퍼바이저에 대한 일반적인 전략은 두 개의 그러한 장치를 갖는 것입니다. 이것은 실제로 하나의 SD 카드와 하나의 USB 드라이브가 될 수 있으며, 각각 하이퍼바이저의 복사본을 가지고 있습니다. 하나의 장치가 고장나면 두 번째 장치로 부팅하는 것이 기존 RAID 1 시스템만큼 효과적입니다. 하지만 대부분의 기존 RAID 1 설정과 달리, 한 번에 하나의 부트 장치만 업데이트하고 두 번째 부트 장치를 업데이트하기 전에 프로세스를 테스트하여 버전 업데이트가 잘못될 경우 신뢰할 수 있고 잘 테스트된 폴백을 남겨두는 방식으로 시스템 업데이트를 테스트할 비교적 쉬운 수단도 있습니다. 이 프로세스는 실제로 부트 장치가 종종 유사한 관행을 지원하는 로컬 소프트웨어 RAID 1 세트였던 대형 UNIX RISC 시스템에서 일반적이었으며 특히 AIX와 Solaris 분야에서 일반적이었습니다.

이 접근 방식이 대부분의 하이퍼바이저 시나리오에서 베스트 프랙티스이지만 물리 하드웨어에 OS를 설치하는 것이 거의 없어야 하는 것을 제외하면 전체 운영 체제 파일 시스템에도 적용할 수 없는 실질적인 이유가 없다는 것도 주목해야 합니다. 그러나 그것은 종종 더 많은 작업입니다. 일부 OS, 특히 Linux와 BSD는 임베디드 방식으로 설치하는 데 매우 뛰어나며 약간의 계획으로 SD 카드나 USB 드라이브에 설치하기 위해 쉽게 조정될 수 있습니다. 이 접근 방식은 전혀 일반적이지 않지만, 올바른 상황에서 훌륭한 접근 방식이 아닐 기술적 이유는 없습니다. 물리 하드웨어에 OS를 직접 설치하는 것보다 하이퍼바이저 위에 OS를 설치해야 하는 경우가 거의 없다는 사실을 제외하면 말이죠. 물리 설치가 필요한 경우라면 이 접근 방식은 매우 유효합니다.

스토리지 시스템을 설계하고 계획할 때 시스템이 실행 중일 때 실제 읽기 및 쓰기 패턴이 어떻게 될지 주의하는 것을 기억하세요. 그리고 많은 기존 지침이 개발된 이후로 스토리지가 상당히 극적으로 변했으며 지침 개발에 사용된 모든 지식이 오늘날에도 동일하게 적용되지는 않는다는 것을 기억하세요. 어떤 스토리지 서브시스템이 스토리지 성능을 사용하려 할지뿐만 아니라 서로 어떻게 상호 작용할지(예를 들어, 두 시스템이 동시에 스토리지 접근을 요청하지 않는지 아니면 정기적으로 충돌할지)와 접근 성능이 중요한지에 대해 생각하세요. 일반 운영 체제 기능은 데이터베이스 서버에서 부정적인 영향 없이 매우 느릴 수 있으며 데이터베이스에 얼마나 빨리 접근할 수 있는지만이 중요합니다. 애플리케이션 바이너리에 대한 접근도 종종 관련이 없습니다. 메모리에 로드되면 거기에 남아 있고 지속적인 성능에는 메모리 속도만이 영향을 미치기 때문입니다.

이것 중 어떤 것도 OS와 데이터 스토리지 서브시스템을 서로 분리하는 것이 권장된다는 것을 의미하지는 않습니다. 종종 그렇지 않습니다. 과거에 이러한 서브시스템을 통합하는 것이 매우 자주 최선의 방법이라고 썼으며 그것은 지금도 사실입니다. 하지만 특정 스토리지 요구 사항을 서로 분리하는 것이 합리적인 많은 경우도 있습니다. 종종 고비용 스토리지를 특정 요구에 전용하고 저비용 스토리지를 다른 요구에 전용하여 비용을 낮출 수 있는 대규모 시스템을 다룰 때가 그러한 경우입니다. 그러한 경우에 운영 체제와 하이퍼바이저는 가장 극단적인 경우를 제외하고는 성능과 신뢰성 모두에서 가장 낮은 우선순위로 고려해야 한다는 것을 보여주고 싶습니다.