고 가용성을 수정하려면 블로그 게시물보다 더 많은 시간이 필요하다는 5 가지 신호

고 가용성을 수정하려면 블로그 게시물보다 더 많은 시간이 필요하다는 5 가지 신호

표지판이 있습니다. 경고등이 깜박입니다.직감에서 느낄 수 있습니다. 잠을 잘 수 없을 수도 있습니다.고 가용성 문제는 심각합니다. 하지만 확실하지 않을 수도 있습니다.

1. 클라우드 SLA가 고 가용성에 필요한 전부라고 생각하는 경우

클라우드 솔루션은 향상된 하드웨어 가용성과 복원력에서 큰 발전을 가져 왔습니다. 그러나 애플리케이션 고 가용성에는 올바른 하이퍼 바이저 또는 클라우드 공급자를 선택하는 것 이상이 필요합니다. 고 가용성을위한 전략은 클라우드 또는 가상화 공급자가 제공하는 SLA로 멈출 수 없습니다. Wired에서 인용 한 바와 같이 "2011 년 4 월에 거의 4 일 동안 발생한 Amazon 중단은 Amazon의 EC2 SLA를 위반하지 않았습니다. FAQ에서 설명하는 것처럼"후행 365 기간 동안 리전 내에서 99.95 %의 서비스 가용성을 보장합니다. " 이 DZone 문서에서 David Bermingham은 클라우드 SLA와 애플리케이션 가용성 간의 차이점을 자세히 설명합니다. 고 가용성 인프라를 원한다면 데이터 및 애플리케이션 계층에서도 모니터링, 복구 및 복원력을 포함해야합니다.

2. 오픈 소스 운영 체제와 함께 제공되는 고 가용성 클러스터링을 사용하는 경우

그렇다면 OS와 함께 제공되는 항목을 기준으로 데이터베이스를 선택하지 않았을 가능성이 있으므로 해당 기준만으로 HA 솔루션을 선택하는 이유는 무엇입니까? 번들 도구는 추가 보증, 가능성 및 기능을 제공하는 데 큰 도움이됩니다. 그러나 액세스 용이성에도 불구하고 번들 도구와 OS 클러스터링 소프트웨어가 항상 SLA, RPO, RTO 및 가용성 요구 사항을 충족 할 수있는 것은 아닙니다. 기업에 운영 체제 조합이있는 경우 팀은 서로 다른 도구를 탐색하고 이들이 어떻게 통합되는지 이해하는 데 도움이 필요할 것입니다. 그것은 마치 울타리 가위를 선택하고 연석에 왼쪽으로 릴 모어를 밀어 13 번 홀 파 5 (Augusta)에있는 "Azalea"모양을 만드는 것과 같습니다. 두 잔디 깎는 기계는 모두 잔디를 깎도록 설계되었지만 시간이 얼마나 있습니까? 복잡성을 어떻게 처리 하시겠습니까? 어느 쪽을 믿으시겠습니까? 고 가용성을위한 전략에는 OS와 함께 제공되는 편의성을 고려하는 것 이상의 것이 필요합니다. 그렇지 않으면 SAP HANA 대신 MySQL을 실행하게됩니다.

3. SQL Enterprise 또는 Oracle Enterprise와 같은 엔터프라이즈 애플리케이션 라이선싱이 엔터프라이즈 고가용 성과 동일하다고 생각하는 경우

비용 증가 외에도 많은 엔터프라이즈 애플리케이션 라이센스는 일부 고 가용성 시나리오에서 애플리케이션의 복구 기능을 증가시킵니다. 그러나 전체 엔터프라이즈가 단일 애플리케이션을 기반으로 할 가능성은 거의 없습니다. 고 가용성에는 고 가용성 데이터베이스 솔루션 이상의 것이 필요합니다. 모든 애플리케이션과 데이터베이스를 광범위하게 지원하는 엔터프라이즈 급 애플리케이션 모니터링 및 복구 솔루션이 필요합니다. 또한 데이터베이스 데이터뿐 아니라 중요한 애플리케이션 및 구성 데이터도 관리하고 복제 할 수있는 기능이 필요합니다. 단일 데이터베이스 또는 간단한 응용 프로그램에 대한 가용성은 한 가지입니다. 그러나 복잡한 다중 부분 응용 프로그램 및 지원 데이터베이스에 대한 HA는 매우 다릅니다. 더 많은 서비스, 조정해야하는 더 많은 부분, 조정해야 할 더 복잡한 아키텍처, 장애 조치 / 전환 전후에 준수해야 할 더 구체적인 모범 사례. 엔터프라이즈 라이선스가 지불 한 것 이상입니다.

4. 다운 타임이 증가하고 가동 시간이 감소하는 경우

삶의 속도는 많은 분야에서 계속 증가하고 있습니다. 팀이 마지막으로 백업에서 복구하거나 중요하다고 간주되는 애플리케이션을 수동으로 다시 시작했거나 실패한 가상 머신 또는 노드 세트를 다시 시작한 것이 언제입니까? 정전 이벤트의 속도가 지속 가능성을 앞지르거나 소방을 넘어서 화재 예방 및 방화로 이동하는 팀의 능력을 능가 할 수는 없습니다. "너는 그렇게 오래 뛸 수있다 (Carey Nieuwhof)." 여러분 중 일부에게는 너무 오랫동안 소방을 해왔고 가동 중단 시간보다 중단이 더 흔해지고 있습니다.

5. 첫 번째 장애 조치 테스트가 프로덕션 서버에있는 경우

최근 고객은 가능한 모든 재난 시나리오를 테스트하는 것은 단순히 불가능하다고 말했습니다. 새로운 소프트웨어가 생성, 배포, 업데이트 및 패치됨에 따라 고 가용성 문제가 증가하고 있습니다. 그러나 라이브 프로덕션 데이터는 함께 잘 작동하지 않는 것을 찾을 수있는 곳이 아닙니다. 그리고 Go-Live와 Post-Go-Live는 항상 놀라움의 몫을 가지고 있지만 실제로 장애 조치를 수행하고 백업 노드에서 실행할 수 없다는 점이 그중 하나가되어서는 안됩니다.

Scouring 블로그는 고 가용성을 정의, 재정의 및 개선하는 데 유용한 팁과 통찰력을 제공 할 수 있습니다. 그러나 '충분히'와 같은 형태로 진정한 가용성을 거래했다는 경고 신호가 나타나면 문제를 해결하기 위해 블로그 게시물 또는 가용성 세계의 모든 블로그 게시물을 수색하는 것 이상이 필요합니다. 귀하의 HA.

– Cassius Rhue, 고객 경험 담당 부사장