2014년에 처음 발표된 이 글은 오늘날에도 여전히 관련성이 있습니다. 하지만 이 이야기는 생각보다 더 깊이 있습니다. 전력 관리에 대한 과감한 설계 결정으로 시작된 것은 Everpure가 전체 스택에 걸쳐 어떻게 탄력성을 접근하는지에 대한 근본적인 것을 보여줍니다.
기존 스토리지에서 어레이를 종료하는 것은 크고 두려우며 손가락으로 교차되는 일종의 거래입니다. 일부 레거시 벤더는 안전한 운영을 위해 지원 또는 Professional Services 팀을 참여시킵니다. 이 절차는 고객이 직접 하지 못하도록 하는 매우 위험합니다. 에버퓨어가 FlashArray를 스크래치로 설계하기 시작했을 때, 우리는 패러다임을 완전히 바꾸도록 도전했습니다. 그러나 문제는 셧다운 절차가 아니라, 전력 손실을 처리할 수 있는 어레이를 구축하여 표준 절차에 따라 플러그를 뽑을 수 있는지 여부였습니다.
그리고 이러한 신뢰 요구 사항은 훨씬 더 큰 것의 씨앗이 되었습니다.
두려운 이중 장애
레거시 스토리지 아키텍처를 살펴보고 데이터 손실 또는 손상이 발생하는 이유를 분석하면, 대부분의 이벤트는 이중 장애로 거슬러 올라갑니다. 드라이브, 컨트롤러, 내부 스위치 등 비교적 사소한 문제가 발생하기 때문에 하루를 절약할 수 있도록 설계된 소프트웨어 복원성 기능 중 하나가 작동됩니다. 여기에서는 일이 흥미로워집니다(“관심” = “정확화”). 이러한 복원성 코드는 종종 매우 과소평가된 코드 기능입니다. 몇 년 전만 해도 아크레인 고장 사례로부터 보호해주고, 당시 테스트를 잘 마친 후, 옷장 뒤에서 잊어버린 와인 한 병처럼 코드 베이스에서 에이징되기 시작했습니다. 단, 시간이 지날수록 더 나아지는 것이 아니라 더 의심스러워집니다.
이 코드는 고장에 안전하기 때문에 프로덕션에서 거의 아무도 사용하지 않으므로, 처음 작성했을 때와 수년 동안 코드 베이스가 진화할 때 모두 소프트웨어 버그의 자석이 됩니다. 따라서 언젠가는 실제 장애로 인해 코드 경로가 필요한 경우, 복원성 코드가 보호해야 할 코드보다 덜 안정적이라는 것을 발견할 수 있습니다. 이는 두 번째 실패로 이어지고 데이터 손실이 발생하지 않도록 합니다. 가족에게 REST 주 동안 저녁식사를 위해 집에 가지 않을 것이라고 말해야 합니다.
Everpure의 철학: 행사되지 않은 코드 없음
FlashArray의 고가용성 및 복원성 기능을 설계하기 시작했을 때, ‘무연행 코드’라는 개념은 Everpure 엔지니어들과 종교적 교리에 가까워졌습니다. 또한, 전력 손실 처리뿐만 아니라 전체 시스템 전반에서 쓰기, 읽기 및 재구축에 대한 생각을 통해 아키텍처 전반에서 이러한 노력이 드러나는 것을 확인할 수 있습니다.
패리티 재구축을 예로 들 수 있습니다. RAID 재구축 코드는 일반적인 읽기/쓰기 경로만큼 안정적이고 성능이 뛰어나야 한다고 생각했기 때문에, 당사는 정상적인 운영의 일부로 패리티에서 지속적으로 읽기 가능한 어레이를 설계했습니다. FlashArray에서 나온 읽기 I/O의 약 15%는 설계상 패리티에서 나옵니다. 이것이 바로 쓰기를 위해 드라이브를 격리하고 I/O 경로를 비차단으로 만드는 방법입니다. 재구축 코드는 긴급 상황에서만 실행되는 코드베이스의 일부 분진이 많은 부분이 아닙니다. 하루 종일 매일 실행됩니다.
플래시FlashArray를 구축하여 컨트롤러 장애 및 장애 조치를 두려워할 필요가 없습니다. 컨트롤러는 상태 비저장 상태이며, 전송 중 쓰기를 포함한 영구 데이터가 없고, HA 이벤트는 비이벤트로 설계되었습니다. 언제든지 Everpure 컨트롤러의 전원을 켜면 성능 저하가 발생하지 않습니다. 뿐만 아니라, 생산 워크로드를 걱정하지 않고 구동하여 하루 중순에 Purity를 업그레이드할 수 있습니다(IT 지크가 선호하는 다른 작업도 있습니다. 벤더가 유지보수 기간에 대해 잘못 알고 있음을 입증합니다).
그리고 전력 손실 처리 자체도 있습니다. FlashArray는 전체 전력 손실을 쉽게 처리할 수 있어야 합니다. 즉, 전체 전력 손실 코드를 업계에서 가장 적게 사용하는 코드 중 하나로 만들어야 했습니다. 우리의 설계 결정은? 이제 어레이를 끄고 전원을 1개씩 동일한 기능으로 끌어올까요? 전력 손실을 관리할 수 있는 역량에 대해 확신을 가져야 했습니다.
모든 것이 실행될 때의 복원력
하지만 더 자세히 살펴보겠습니다. 전원 버튼 스토리는 모든 FlashArray I/O 작업을 지속적으로 실행하는 복원력에 대한 훨씬 포괄적인 접근 방식의 가시적인 증상일 뿐입니다.
쓰기가 FlashArray에 도착하면, 데이터는 확인이 이루어지기 전에 동시에 4개의 위치에 기록됩니다. 즉, 어레이의 스토리지 쉘프에 있는 이중화 NVRAM 장치에 있는 2개의 사본과 두 컨트롤러의 DRAM에 있는 작업 사본이 모두 기록됩니다. 여기서는 무슨 일이 일어나지 않는지 알아두세요. 어레이는 정전 시 휘발성 컨트롤러 메모리에서 데이터를 디스테이징하려고 하지 않으며, 모든 것을 디스크로 플러시할 수 있을 만큼 오래 작동하기 위해 일부 취약한 UPS 아키텍처에 의존하지 않습니다. 쓰기는 호스트에게 전송되기 전에 4개의 보호된 위치에 적용됩니다. 즉, 어떤 시점에서도 전력 손실은 문제가 되지 않습니다.
이러한 보호는 RAID 계층까지 확장됩니다. FlashArray는 RAID의 한 형태를 사용해 드라이브 장애로부터 보호하지만, 후드 아래에는 더 많은 것이 있습니다. RAID 재구축 작업은 일반적인 읽기 작업과 동일한 코드 경로를 사용하도록 시스템을 설계했습니다. 제가 앞서 언급한 패리티에서 나온 글의 15%는? 이는 유휴 시간 동안 실행되는 백그라운드 검증 작업이 아닙니다. 일반적인 I/O 스케줄러는 쓰기를 위해 드라이브를 격리하고 I/O 경로를 비차단 상태로 유지하면서 읽기 요청을 충족하는 방법에 대한 지능적인 결정을 내립니다.
DFM이 고장나고 재구축이 필요한 경우(매우 드물게 발생하는 경우), 재해 발생 시에만 실행되는 먼지가 많은 비상 절차를 도입하지 않습니다. 우리는 수십억 개의 I/O 작업을 처리하는 첫날부터 지속적으로 실행되는 동일한 패리티 읽기 메커니즘을 사용하고 있습니다. 재구축 코드는 생산 워크로드에 의해 매일 전투 테스트를 거칩니다. 필요할 때 여전히 작동되기를 바라며 윙에서 기다리지 않습니다.
스테이트리스 컨트롤러의 장점
그리고 이러한 ‘행사되지 않은 코드 없음’이라는 철학은 컨트롤러 고장을 처리하는 방법에도 나타납니다. FlashArray는 듀얼 컨트롤러 아키텍처를 사용하며, 상태 비저장 상태이므로, 전송 중 쓰기를 포함한 영구 데이터를 보유하지 않습니다. 앞서 언급한 4개 위치에서는 NVRAM에 2부, 두 컨트롤러의 DRAM에 작업 복사본 등 중요한 모든 것이 이미 보호되어 있습니다.
이는 실제로 성능에 영향을 미치거나 데이터를 위험에 빠뜨리지 않고 언제든지 컨트롤러에서 전원을 가져올 수 있다는 것을 의미합니다. HA 페일오버는 긴급 절차를 촉발하는 무서운 사건이 아니라, 무사한 사건이 아닙니다. 또한, 컨트롤러 페일오버는 정기적으로 발생하는 또 다른 정상 운영(소프트웨어 업그레이드, 유지보수, 테스트)이기 때문에 코드 경로는 선명하게 유지됩니다. 페일오버 메커니즘이 필요할 때 작동하길 바라지 않고, 일상적인 운영의 일부로 일상적으로 실행하고 있습니다.
이를 통해 전원 버튼(또는 부족함)으로 돌아갑니다.
FlashArray를 어떻게 끄나요?
이제 해답을 찾을 수 있습니다. 전원 코드를 뽑기만 하면 됩니다. 전 아시다시피, 적대적입니다.
퓨어스토리지는 컨트롤러에 표준 기성 하드웨어 컴포넌트를 사용하기 때문에, 선반과 컨트롤러에 기술적으로 기존의 물리적 전원 버튼이 있지만, 이러한 버튼은 전적으로 선택 사항이며, 실제로 권장되지 않습니다. GUI에는 종료 버튼이 없고 CLI에는 정교한 종료 절차를 시작하는 명령이 없습니다. 전원을 끄려면 전원을 끄면 됩니다. 복구 시간? 컨트롤러를 부팅하는 데 걸리는 시간은 3분 정도입니다.
이는 무모한 것이 아닙니다. 이는 I/O 수준에서 우리가 내린 아키텍처적 결정에서 비롯된 자신감입니다. 모든 쓰기는 승인 전에 4개 위치에서 보호되며, 모든 읽기는 장애를 처리하는 동일한 코드 경로에서 실행됩니다. 이는 운영에 영향을 주지 않고 장애 조치할 수 있는 스테이트리스 컨트롤러에 의해 지원됩니다. 모든 재구축 작업은 매일 프로덕션 워크로드를 지원하는 동일한 메커니즘을 사용합니다.
이것이 여러분에게 의미하는 바
복원력과 가용성에 대한 약속을 하는 다른 벤더와 비교하여 Everpure를 평가하는 경우, 몇 가지 상식적인 테스트를 제안합니다. 전체 전력 손실 시나리오에 대해 물어보세요. 코드 작동 방식, 보호 수준, 경고 사항, 복구 소요 시간 그리고 답을 들은 후, 개념 증명 중에 테스트하세요. 대용량 워크로드를 실행하고, 랙에 전원을 공급하고, 전원을 복구하고, 어레이 복구에 걸리는 시간(및 복구 여부)을 확인하세요. 그리고 해당 절차가 벤더Proof of Concept 가이드의 일부가 아닌 경우, 이를 포함시키도록 주장합니다.
더 좋은 점은, 재구축 운영에 대해 물어보세요. 정상 운영 중에 해당 코드가 얼마나 자주 실행되나요? 드라이브가 고장나고 재구축이 시작되면 성능은 어떻게 되나요? 또 다른 블로그에서 이에 대해 이야기했습니다. 복구의 성능 품질은 장애가 발생할 때 시스템이 작동하는 데 구축된 복원성만큼이나 중요합니다.
플래시FlashArray를 구축하는 방법을 배웠습니다. 엣지 케이스를 처리하는 방식은 아키텍처에 대한 모든 것을 보여줍니다. 전력 손실이 안전한 관리를 위해 정교한 절차가 필요한 무서운 특수 사례인 경우, 이는 시스템에 적용된 기본적인 설계 가정에 대해 알려줍니다. 재구축이 성능을 저하시키고 재구축 기간 동안 위험에 처할 수 있는 비상 작업인 경우, 이는 시스템이 정상 작동 조건으로 고장이 발생하지 않도록 설계되었다는 것을 의미합니다.
에버퓨어는 FlashArray가 설계되었을 때 이러한 모든 위험에 도전했습니다. 이는 모든 것이 이미 잘못되었을 때만 실행되는 특수 사례 코드로 분리되는 것이 아니라 모든 I/O 작업의 정상적인 흐름에 내장되어 지속적으로 실행되고, 암묵적으로 신뢰되며, 실패 처리가 불가능해지도록 신뢰할 수 있어야 한다고 생각하기 때문입니다.
시간을 내어 이러한 차이점을 이해하세요. 유지보수를 위해 전원을 끌 때 뿐만 아니라, 매일 스토리지가 미션 크리티컬 프로덕션 워크로드를 실행하고 있습니다. 이는 수십억 개의 I/O 운영으로 테스트된 복원성을 원할 때이며, 이미 매우 악천후를 겪고 있을 때만 테스트되는 복원성은 필요로 하지 않습니다.
데이터 처리 방법 재정의
에버퓨어는 사람들이 데이터를 소비하고 상호 작용하는 방식을 간소화하여 스토리지 경험을 재정의하고 혁신가들에게 권한을 부여합니다.
Everpure 플랫폼이 장기 엔터프라이즈 스토리지 전략을 지원하는 방법에 대해 이야기하고 싶으신가요? 그 대화를 해봅시다.
