홍수가 나더라도 1C는 작동합니다! 우리는 DR 사업에 동의합니다

당신이 대형 쇼핑 센터의 IT 인프라를 서비스하고 있다고 상상해 보십시오. 도시에 비가 내리기 시작합니다. 빗줄기가 지붕을 뚫고 들어오고, 소매점에는 발목까지 물이 가득 차 있습니다. 귀하의 서버실이 지하에 있지 않기를 바랍니다. 그렇지 않으면 문제를 피할 수 없습니다.  

설명된 이야기는 환상이 아니라 2020년의 몇 가지 사건에 대한 집합적인 설명입니다. 대기업에서는 이러한 경우를 대비하여 재해 복구 계획 또는 재해 복구 계획(DRP)이 항상 준비되어 있습니다. 기업에서는 이것이 비즈니스 연속성 전문가의 책임입니다. 그러나 중소기업에서는 이러한 문제를 해결하는 것이 IT 서비스에 달려 있습니다. 비즈니스 로직을 스스로 이해하고, 무엇이 실패할 수 있는지, 어디에서 실패할 수 있는지 이해하고, 보호책을 마련하고 구현해야 합니다. 

IT 전문가가 비즈니스와 협상하고 보호의 필요성에 대해 논의할 수 있다면 좋습니다. 하지만 한 회사에서 재해 복구(DR) 솔루션이 중복된다고 생각하여 인색하게 되는 경우를 여러 번 보았습니다. 사고가 발생했을 때 장기간의 복구로 인해 손실이 발생할 위험이 있었고 사업은 준비되지 않았습니다. 원하는 만큼 "내가 그렇게 말했지"라고 반복할 수 있지만 IT 서비스는 여전히 서비스를 복원해야 합니다.

이런 상황을 피하는 방법을 건축가의 입장에서 알려드리겠습니다. 기사의 첫 번째 부분에서는 준비 작업, 즉 보안 도구 선택을 위해 고객과 세 가지 질문을 논의하는 방법을 보여 드리겠습니다. 

• 우리는 무엇을 보호하고 있나요?
• 우리는 무엇으로부터 보호하고 있나요?
• 우리는 얼마나 보호하고 있나요? 

두 번째 부분에서는 자신을 방어하는 방법이라는 질문에 답하기 위한 옵션에 대해 이야기하겠습니다. 다양한 고객이 보호 기능을 구축하는 방법에 대한 사례를 제시하겠습니다.

우리가 보호하는 것: 중요한 비즈니스 기능 식별 

비즈니스 고객과 비상사태 후 조치 계획을 논의하여 준비를 시작하는 것이 좋습니다. 여기서 가장 큰 어려움은 공통 언어를 찾는 것입니다. 고객은 일반적으로 IT 솔루션의 작동 방식에 관심이 없습니다. 그는 서비스가 비즈니스 기능을 수행하고 수익을 창출할 수 있는지 여부에 관심을 갖습니다. 예를 들어, 사이트는 작동하지만 결제 시스템이 다운된 경우 고객으로부터 수입이 없으며 "극단주의자"는 여전히 IT 전문가입니다. 

IT 전문가는 다음과 같은 이유로 협상에 어려움을 겪을 수 있습니다.

• IT 서비스는 비즈니스에서 정보 시스템의 역할을 완전히 이해하지 못합니다. 예를 들어 비즈니스 프로세스에 대한 설명이나 투명한 비즈니스 모델이 없는 경우입니다. 
• 전체 프로세스가 IT 서비스에 의존하는 것은 아닙니다. 예를 들어 작업의 일부가 계약업체에 의해 수행되고 IT 전문가가 해당 작업에 직접적인 영향을 미치지 않는 경우입니다.

나는 다음과 같이 대화를 구성하겠습니다. 

1. 사고는 누구에게나 발생하며 회복에는 시간이 걸린다는 점을 기업에 설명합니다. 가장 좋은 방법은 상황, 이것이 어떻게 발생하는지, 어떤 결과가 발생할 수 있는지를 보여주는 것입니다.
2. 우리는 모든 것이 IT 서비스에 달려 있는 것은 아니지만 귀하의 책임 영역에 대한 실행 계획을 도울 준비가 되어 있음을 보여줍니다.
3. 비즈니스 고객에게 질문합니다. 세상의 종말이 발생하면 어떤 프로세스를 먼저 복원해야 합니까? 누가, 어떻게 참여하나요? 

   비즈니스에서는 간단한 답변이 필요합니다. 예를 들어 콜센터는 연중무휴 24시간 계속해서 애플리케이션을 등록해야 합니다.

4. 우리는 시스템 사용자 한두 명에게 이 프로세스에 대해 자세히 설명해달라고 요청합니다. 
   회사에 분석가가 있는 경우 도움을 줄 분석가를 참여시키는 것이 좋습니다.

   우선 설명은 다음과 같습니다. 콜센터는 전화, 우편 및 웹 사이트의 메시지를 통해 요청을 받습니다. 그런 다음 웹 인터페이스를 통해 1C에 입력하고 프로덕션에서는 이런 방식으로 해당 항목을 가져옵니다.

5. 그런 다음 어떤 하드웨어 및 소프트웨어 솔루션이 프로세스를 지원하는지 살펴봅니다. 포괄적인 보호를 위해 우리는 세 가지 수준을 고려합니다. 
   • 사이트 내의 애플리케이션 및 시스템(소프트웨어 수준)   
   • 시스템이 실행되는 사이트 자체(인프라 수준) 
   • 네트워크(그들은 종종 잊어버립니다).

6. 우리는 가능한 실패 지점, 즉 서비스 성능이 좌우되는 시스템 노드를 찾아냅니다. 통신 사업자, 호스팅 제공업체, 데이터 센터 등 다른 회사에서 지원하는 노드를 별도로 기록합니다. 이를 통해 다음 단계를 위해 비즈니스 고객에게 돌아갈 수 있습니다.

우리가 보호하는 것: 위험

다음으로 우리는 비즈니스 고객으로부터 어떤 위험으로부터 우리 자신을 보호하는지 먼저 알아봅니다. 모든 위험은 두 그룹으로 나눌 수 있습니다. 

• 서비스 중단 시간으로 인한 시간 손실;
• 물리적 충격, 인적 요인 등으로 인한 데이터 손실

기업은 데이터와 시간을 모두 잃을까 봐 두려워합니다. 이 모든 것이 돈 손실로 이어집니다. 따라서 다시 각 위험 그룹에 대해 질문합니다. 

• 이 과정에서 데이터 손실과 시간 손실 비용을 돈으로 얼마나 추정할 수 있나요? 
• 어떤 데이터를 잃어서는 안 되나요? 
• 가동 중지 시간을 허용할 수 없는 곳은 어디입니까? 
• 어떤 사건이 우리에게 가장 가능성이 높고 가장 위협적인가?

논의 후, 실패 지점의 우선순위를 정하는 방법을 이해하게 됩니다. 

우리가 보호하는 정도: RPO 및 RTO 

중요한 실패 지점이 명확해지면 RTO 및 RPO 지표를 계산합니다. 

나는 너에게 상기 시키겠다. RTO(복구 시간 목표) - 사고 발생 시점부터 서비스가 완전히 복구될 때까지 허용되는 시간입니다. 비즈니스 언어에서는 이는 허용 가능한 가동 중지 시간입니다. 프로세스로 인해 발생한 비용이 얼마나 되는지 안다면 가동 중지 시간의 매 분당 손실을 계산하고 허용 가능한 손실을 계산할 수 있습니다. 

RPO(복구 지점 목표) — 유효한 데이터 복구 지점. 데이터가 손실될 수 있는 시간을 결정합니다. 예를 들어, 비즈니스 관점에서 데이터 손실로 인해 벌금이 부과될 수 있습니다. 이러한 손실은 돈으로 환산될 수도 있습니다. 

최종 사용자에 대한 복구 시간, 즉 시스템에 로그인할 수 있는 시간을 계산해야 합니다. 먼저 체인에 있는 모든 링크의 복구 시간을 합산합니다. 여기서 실수가 자주 발생합니다. SLA에서 공급자의 RTO를 가져오고 나머지 조건은 잊어버립니다.

구체적인 예를 살펴 보겠습니다. 사용자가 1C에 로그인하면 시스템이 데이터베이스 오류와 함께 열립니다. 그는 시스템 관리자에게 연락합니다. 데이터베이스는 클라우드에 있으며 시스템 관리자는 서비스 제공자에게 문제를 보고합니다. 모든 통신에 15분이 걸린다고 가정해 보겠습니다. 클라우드에서는 이 크기의 데이터베이스가 15시간 안에 백업에서 복원되므로 서비스 제공업체 측의 RTO는 XNUMX시간입니다. 하지만 이는 최종 기한이 아니며 사용자의 경우 문제 감지를 위해 XNUMX분이 추가되었습니다. 
 
다음으로 시스템 관리자는 데이터베이스가 올바른지 확인하고 이를 1C에 연결한 후 서비스를 시작해야 합니다. 이를 위해서는 2시간이 더 필요합니다. 이는 관리자 측의 RTO가 이미 15시간 15분임을 의미합니다. 사용자에게는 2분이 더 필요합니다. 로그인하여 필요한 트랜잭션이 나타나는지 확인하세요. 이 예에서 총 서비스 복구 시간은 30시간 XNUMX분입니다.

이러한 계산을 통해 비즈니스는 복구 기간이 어떤 외부 요인에 의존하는지 알 수 있습니다. 예를 들어 사무실이 침수된 경우 먼저 누수 지점을 찾아 수리해야 합니다. IT에 의존하지 않는 데는 시간이 걸립니다.  

보호 방법: 다양한 위험에 대한 도구 선택

모든 사항을 논의한 후 고객은 이미 사고로 인한 비즈니스 비용을 이해하고 있습니다. 이제 도구를 선택하고 예산에 대해 논의할 수 있습니다. 고객 사례의 예를 사용하여 다양한 작업에 어떤 도구를 제공하는지 보여 드리겠습니다. 

첫 번째 위험 그룹인 서비스 중단 시간으로 인한 손실부터 시작해 보겠습니다. 이 문제에 대한 솔루션은 우수한 RTO를 제공해야 합니다.

1. 클라우드에서 애플리케이션 호스팅 

   우선, 간단히 클라우드로 이동할 수 있습니다. 공급자는 이미 고가용성 문제를 고려했습니다. 가상화 호스트는 클러스터로 조립되고, 전원과 네트워크는 예약되며, 데이터는 내결함성 스토리지 시스템에 저장되며, 서비스 제공업체는 다운타임에 대한 재정적 책임을 집니다.

   예를 들어 클라우드에 데이터베이스가 있는 가상 머신을 호스팅할 수 있습니다. 애플리케이션은 설정된 채널을 통해 또는 동일한 클라우드에서 외부적으로 데이터베이스에 연결됩니다. 클러스터의 서버 중 하나에 문제가 발생하면 VM은 2분 이내에 인접 서버에서 다시 시작됩니다. 그 후 DBMS가 시작되고 몇 분 안에 데이터베이스를 사용할 수 있게 됩니다.

   RTO: 분 단위로 측정됩니다. 이러한 조건은 공급자와의 계약에 명시될 수 있습니다.
   비용: 귀하의 애플리케이션에 대한 클라우드 리소스 비용을 계산합니다. 
   그것이 당신을 보호하지 못하는 것: 예를 들어 도시 수준의 사고로 인해 공급자 사이트의 대규모 실패로 인해 발생합니다.

2. 애플리케이션 클러스터링  

   RTO를 개선하려면 이전 옵션을 강화하고 클러스터링된 애플리케이션을 클라우드에 즉시 배치할 수 있습니다.

   활성-수동 또는 활성-활성 모드로 클러스터를 구현할 수 있습니다. 공급업체의 요구 사항에 따라 여러 VM을 만듭니다. 신뢰성을 높이기 위해 다양한 서버와 스토리지 시스템에 배포합니다. 데이터베이스 중 하나가 있는 서버에 오류가 발생하면 백업 노드가 몇 초 안에 로드를 인계받습니다.

   RTO: 초 단위로 측정됩니다.
   비용: 일반 클라우드보다 약간 비싸며 클러스터링을 위해서는 추가 리소스가 필요합니다.
   그것이 당신을 보호하지 못하는 것: 여전히 대규모 현장 오류로부터 보호되지 않습니다. 그러나 지역적 혼란은 오래 가지 않을 것입니다.

   연습부터: 해당 소매업체에는 여러 정보 시스템과 웹사이트가 있었습니다. 모든 데이터베이스는 회사 사무실에 로컬로 위치해 있었습니다. 사무실에 여러 번 연속으로 전원이 끊길 때까지 DR은 고려되지 않았습니다. 고객은 웹사이트 충돌로 인해 불만을 나타냈습니다. 
    
   클라우드로 이전 후 서비스 가용성 문제가 해결되었습니다. 또한 노드 간 트래픽 균형을 조정하여 데이터베이스의 로드를 최적화했습니다.

3. 재해 방지 클라우드로 전환

   메인 사이트에 자연재해가 발생해도 업무에 지장을 주지 않으려면 재해 방지 클라우드를 선택하면 되는데, 이 옵션에서는 공급자가 가상화 클러스터를 2개의 데이터 센터에 분산시킵니다. 데이터 센터 간에 일대일로 지속적인 동기식 복제가 발생합니다. 데이터 센터 간의 채널은 예약되어 있으며 서로 다른 경로를 따르므로 이러한 클러스터는 네트워크 문제를 두려워하지 않습니다. 

   RTO: 0이 되는 경향이 있습니다.
   비용: 가장 비싼 클라우드 옵션입니다. 
   그것이 당신을 보호하지 못하는 것: 데이터 손상은 물론 인적 측면에서도 도움이 되지 않으므로 동시에 백업하는 것을 권장합니다. 

   연습부터: 우리 고객 중 한 명이 포괄적인 재해 복구 계획을 개발했습니다. 그가 선택한 전략은 다음과 같습니다. 

   • 재해 방지 클라우드는 인프라 수준에서 장애로부터 애플리케이션을 보호합니다. 
   • XNUMX단계 백업은 사람의 실수에 대비한 보호 기능을 제공합니다. 백업에는 "콜드"와 "핫"의 두 가지 유형이 있습니다. "콜드" 백업은 비활성화된 상태이며 배포하는 데 시간이 걸립니다. "핫" 백업은 이미 사용할 준비가 되어 있으며 더 빠르게 복원됩니다. 특별히 전용 스토리지 시스템에 저장됩니다. 세 번째 사본은 테이프에 녹음되어 다른 방에 보관됩니다. 

   일주일에 한 번씩 클라이언트는 보호 기능을 테스트하고 테이프 백업을 포함한 모든 백업의 기능을 확인합니다. 매년 회사는 재해 방지 클라우드 전체를 테스트합니다. 

4. 다른 사이트로의 복제 구성 

   메인 사이트의 글로벌 문제를 방지하는 방법에 대한 또 다른 옵션은 지리적 예약을 제공하는 것입니다. 즉, 다른 도시의 사이트에 백업 가상 머신을 생성합니다. DR을 위한 특수 솔루션이 이에 적합합니다. 우리 회사에서는 vCAV(VMware vCloud Availability)를 사용합니다. 이를 통해 여러 클라우드 공급자 사이트 간에 보호를 구성하거나 온프레미스 사이트에서 클라우드로 복원할 수 있습니다. vCAV 작업 계획에 대해 이미 자세히 설명했습니다. 여기에. 

   RPO 및 RTO: 5분부터. 

   비용: 첫 번째 옵션보다 비싸지만 재해 방지 클라우드에서 하드웨어 복제보다 저렴합니다. 가격은 vCAV 라이선스 비용, 관리 비용, 클라우드 리소스 비용, PAYG 모델에 따른 예약 리소스 비용(전원이 꺼진 VM의 작업 리소스 비용의 10%)으로 구성됩니다.

   연습부터: 클라이언트는 모스크바의 클라우드에 서로 다른 데이터베이스를 가진 6개의 가상 머신을 보관했습니다. 처음에는 백업을 통해 보호가 제공되었습니다. 백업 복사본 중 일부는 모스크바의 클라우드에 저장되었고 일부는 상트페테르부르크 사이트에 저장되었습니다. 시간이 지남에 따라 데이터베이스 크기가 커지고 백업에서 복원하는 데 더 많은 시간이 걸리기 시작했습니다. 
    
   VMware vCloud Availability를 기반으로 한 복제가 백업에 추가되었습니다. 가상 머신의 복제본은 상트페테르부르크의 백업 사이트에 저장되며 5분마다 업데이트됩니다. 메인 사이트에 장애가 발생하면 직원들은 독립적으로 상트페테르부르크에 있는 가상 머신의 복제본으로 전환하여 계속 작업합니다. 

고려된 모든 솔루션은 고가용성을 제공하지만 랜섬웨어 바이러스 또는 우발적인 직원 실수로 인한 데이터 손실로부터 보호하지 못합니다. 이 경우 필요한 RPO를 제공하는 백업이 필요합니다.

5. 백업을 잊지 마세요

가장 멋진 재해 방지 솔루션이 있더라도 백업이 필요하다는 것은 누구나 알고 있습니다. 그래서 몇 가지 사항만 간략하게 알려드리겠습니다.

엄밀히 말하면 백업은 DR이 아닙니다. 그 이유는 다음과 같습니다. 

• 오랜만이에요. 데이터가 테라바이트 단위로 측정되면 복구하는 데 XNUMX시간 이상이 걸립니다. 복원하고, 네트워크를 할당하고, 켜져 있는지 확인하고, 데이터가 올바른지 확인해야 합니다. 따라서 데이터가 적은 경우에만 좋은 RTO를 제공할 수 있습니다. 
• 처음에는 데이터가 복원되지 않을 수 있으므로 작업을 반복할 시간이 필요합니다. 예를 들어, 데이터가 언제 손실되었는지 정확히 알 수 없는 경우가 있습니다. 손실이 15.00시에 발견되었고 매 시간마다 복사본이 만들어졌다고 가정해 보겠습니다. 15.00시부터 모든 복구 지점(14:00, 13:00 등)을 살펴봅니다. 시스템이 중요한 경우 복구 지점의 수명을 최소화하려고 노력합니다. 그러나 새 백업에 필요한 데이터가 포함되어 있지 않은 경우 다음 단계를 수행합니다. 이는 추가 시간입니다. 

이 경우 백업 일정은 필요한 것을 제공할 수 있습니다. RPO. 백업의 경우 메인 사이트에 문제가 있을 경우를 대비해 지리적 예약을 제공하는 것이 중요합니다. 일부 백업 복사본을 별도로 저장하는 것이 좋습니다.

최종 재해 복구 계획에는 최소한 두 가지 도구가 포함되어야 합니다.  

• 시스템 장애 및 추락으로부터 시스템을 보호하는 옵션 1-4 중 하나입니다.
• 데이터 손실을 방지하기 위해 백업합니다. 

주요 인터넷 제공업체가 다운될 경우를 대비해 백업 통신 채널을 관리하는 것도 가치가 있습니다. 그리고 - 짜잔! — 최저 임금 DR은 이미 준비되어 있습니다. 

출처 : habr.com