웹사이트에 대한 간단한 장애 조치(모니터링 + 동적 DNS)

이 기사에서는 모니터링 조합을 사용하여 웹 사이트(또는 기타 인터넷 서비스)에 대한 장애 조치 계획을 얼마나 쉽고 무료로 만들 수 있는지 보여주고 싶습니다. 오케르 동적 DNS 서비스. 즉, 메인 사이트에 문제가 있는 경우(페이지의 "PHP 오류" 문제, 공간 부족 또는 온라인 상점의 경우 의심스러울 정도로 적은 주문 수), 신규 방문자는 알려진 작동 서버의 두 번째(세 번째 등)로 이동하거나 "죄송합니다" 페이지에서 "문제가 있습니다. 우리는 이미 알고 있고 해결 중입니다. "라고 정중하게 설명합니다. 곧 수정하겠습니다.”(이 경우 실제로 이미 알고 있으므로 수리할 수 있습니다.)

장애 조치(failover)를 사용하거나 사용하지 않고 살 수 있습니까?

어떤 문제가 발생하기 전까지는 별 차이가 없습니다. 그러나 이런 일이 발생하면 장애 조치 없이 다음과 같은 일이 자주 발생합니다. 문제가 무엇인지 빨리 파악하려고 시도하지만 작동하지 않습니다(백업이 배포되지 않고 어떤 이유로 소프트웨어가 문서에 나와 있는 대로 작동하지 않음). 등), 하지만 시간도 없고 서버도 없습니다. 사이트가 주변에 있고, 클라이언트가 전화를 걸고, 모두가 불안에 떨고 있으며, 어떻게든 "테이프로" 거칠고 더러워진 문제를 해결하려고 시도하다가 어떻게든 시작되는 것 같습니다. 목발과 생명으로. 여가 시간에는 더 자세히 파악하고 모든 것을 아름답게 다시 실행해야 한다고 생각하지만 일시적인 것보다 더 영구적인 것은 없습니다.

이제 파일러가 있는 아름다운 버전에서 이것이 어떻게 발생합니까?

• 실수가 일어나다
• 오류가 자동으로 감지됩니다.
• 경고가 전송됩니다
• 백업 서버 중 하나로 전환이 전송됩니다.
• 당황하지 않고 침착하게 문제를 정리하고 수정한 후 서버를 다시 작동시킵니다.

물론 이 체계에는 자체적인 문제가 있을 수도 있지만 여전히 체계는 선형이고 각 단계가 간단하며 중요한 것은 개별적으로 디버깅할 수 있다는 점이므로 이 체계가 실패할 확률은 훨씬 낮습니다. 모든 작업은 자동화되고 신속하게 수행될 수 있습니다(알려지지 않은 서사시를 찾아서 수정하는 작업과 달리). 비행기가 먼 나라에 착륙했습니다. 휴대폰을 켜고 서버가 충돌했다는 알림을 전보에서 확인했지만 모든 것이 정상입니다. 백업 서버가 활성화되었으므로 여행을 계속할 수 있으며 필요하지 않습니다. 비행기로 돌아가거나 WiFi가 있는 가장 가까운 카페에서 SSH를 통해 수리하세요. 더 편리해지면 알게 될 것입니다.

미래는 이미 여기에 있습니다!

이전에는 장애 조치를 종종 수용할 수 없는 솔루션으로 만들었던 주요 문제는 비용 문제였습니다. 아니면 값비싼 하드웨어를 구입해야 했습니다(더 값비싼 전문가를 초대해야 했습니다). 또는 가이드에 따르면 집단 농장이 뭔가 복잡합니다. 두 개의 서버가 널 모뎀 케이블로 추가로 연결되어 이를 통해 하트비트를 보내 적시에 백업 서버가 이를 인식하고 인계받는 옵션도 발견했습니다. 제어). 이제 더 쉽고 자유로운 방법이 있습니다. 고양이가 있는 웹사이트가 있다면 아직 장애 조치를 구현하지 않을 이유가 없습니다!

게다가, 장애 조치 계획을 위해서는 또 다른 서버(아마도 하나 이상)가 필요하며 이것이 큰 비용이 되기 전에 이제는 아주 저렴한 VDS를 얻을 수 있습니다.

고양이와 함께하는 가장 믿을 수 있는 사이트

okrr + 동적 DNS를 사용한 솔루션을 실제로 설명하기 위해 고양이와 함께 웹사이트를 시작했습니다. cat.okerr.com. 우리는 고양이를 싫어해서 그곳에 고양이가 많지 않을 거예요. 총 1개의 사이트가 있으며 각 사이트는 거의 동일해 보이지만(모두 동일한 템플릿에 있음) 쉽게 구별할 수 있도록 새끼 고양이가 다르며 각 사이트는 장애 조치가 어떻게 작동하는지 확인하기 위한 기술 정보를 작성합니다. 페이지는 XNUMX분마다 한 번씩 업데이트되지만 언제든지 브라우저에서 다시 로드를 클릭할 수 있습니다.

기술 정보에 "status=OK"라는 줄이 있습니다. 때때로 서버가 문제를 가장하고 status=ERR이라고 기록하는 경우가 있습니다. 매시 20분(0:20, 1:20, 2:20, …)에 메인 서버가 “충돌하는 것 같습니다”. 40분 안에 서버를 백업하세요. 마지막 서버("sorry" 서버)는 항상 실행 중입니다. 매시 0분이 되면 기본 서버와 백업 서버가 "복원"됩니다.

사이트를 열고 탭에 놔두면 절대 충돌이 발생하지 않으며(각 개별 서버는 주기적으로 문제를 시뮬레이션하지만), 서버에 문제가 발생하면 라이브 서버 간에 단순히 "실행"되는 것을 볼 수 있습니다. 서버의 사진, 이름, 주소 및 역할이 변경됩니다. 때로는 status = ERR(문제가 이미 존재하지만 전체 장애 조치 체계가 아직 작동하지 않음)인 순간을 포착할 수 있지만 다음 업데이트에서는 작업 중인 사이트의 페이지가 표시됩니다.

okrr + 동적 DNS의 장애 조치

내부적으로 어떻게 작동하는지 살펴보겠습니다. 파일러의 임무는 cat.okerr.com 주소가 항상 작업 서버의 IP 주소를 가리키는지 확인하는 것입니다.
okrr에서 고양이 사이트를 호스팅하는 각 서버 뒤에는 XNUMX분에 한 번씩 상태를 확인하는 표시기가 있습니다.

이 스크린샷에서는 alpha.okerr.com 서버에서 cat.okerr.com 사이트를 확인하는 방법을 보여줍니다. 페이지에는 status=OK가 포함되어야 하며 위에서 볼 수 있듯이 이제 표시기 상태는 OK입니다. 서버가 "중단"되면 ERR이 발생합니다. (이것은 표시기의 한 예일 뿐이며 oker는 모니터링하므로 모든 유형의 표시기를 연결할 수 있습니다. 예를 들어 디스크의 여유 공간, 데이터베이스의 새 주문 수, 심지어 논리적 표시기 등을 확인할 수 있습니다. , 밤에는 몇 가지 오류 기준이 있고 낮에는 다른 기준이 있습니다.

프로젝트 설정에서 우리는 다음 지표를 사용하여 장애 조치 체계를 만들었습니다.

이 구성표에는 우선순위가 다른 XNUMX개의 지표(XNUMX개의 서버)가 있습니다. 사이트의 기본 서버는 charlie입니다. 작동하지 않으면("status=OK"가 없거나 간단히 사용할 수 없는 경우) bravo이고 후자의 경우에는 alpha입니다. 페이지 오른쪽에는 여러 서버의 DNS 레코드 상태가 표시됩니다.

cat.he.okerr.com이라는 이름이 사용된 것을 알아차린 사람들을 위해: 우리는 약간 더 복잡한 체계를 사용합니다. cat.okerr.com의 DNS 레코드를 변경하는 대신 cat.he.okerr.com을 변경합니다(동적 DNS 공급자에서). 허리케인 일렉트릭), cat.okerr.com은 변경되지 않는 CNAME(별칭)이며 항상 cat.he.okerr.com을 가리킵니다. 우리는 동적 DNS인 Hurricane을 더 좋아하며 여기에는 (전체 영역이 아닌) 단일 항목을 관리할 수 있는 키가 있으므로 더 안전하다고 생각합니다. 또한 전체 도메인을 관리하기 위해 oker에 키 비밀번호를 지정할 필요는 없지만 하위 도메인이나 레코드에 대해서만 지정할 수 있습니다.

하락에서 상승으로

이 계획이 어떻게 작동하는지 단계별로:

1. 서버에 문제가 발생(시뮬레이션)됨
2. okrr 센서는 XNUMX분에 한 번씩 각 서버의 상태를 확인하여 okerr로 메인 프로젝트 서버에 보고합니다.
3. 해당 서버 표시기가 OK에서 ERR로 변경됩니다.
4. 표시기의 상태가 변경되면 장애 조치가 다시 계산되고 어떤 주소를 설정해야 하는지 계산됩니다(필요한 경우). 예를 들어 주 서버가 작동 중이고 동시에 백업 서버가 종료되면 변경 사항이 없습니다. 만들어진)
5. 이 주소는 동적 DNS 서비스에 보고됩니다. 이 단계가 완료되면 오른쪽에 "동기화됨" 상태가 표시됩니다.
6. 곧(초) 레코드가 도메인의 DNS 서버(고양이 사이트의 경우 ns1-ns5.he.net)에 도달합니다.
7. 지금부터 일부 사용자는 이미 새로운 라이브 서버에 접속하고 있을 것입니다. 그러나 전 세계의 모든 DNS 서버가 아직 레코드를 업데이트한 것은 아니며 이전 레코드가 여전히 어딘가에 캐시되어 있을 수 있습니다. 공용 DNS 서버의 데이터가 어떻게 "춤"을 추며 새 값이나 이전 값을 표시하는지 확인할 수 있습니다. 장애 조치 구성 페이지를 업데이트하면 운영자 자체가 DNS 서버에 새 데이터를 요청합니다.
8. 데이터가 안정화된 후에는 이전에 캐시된 기록이 모든 곳에서 부패됩니다. 모든 요청이 100% 새 서버로 이동합니다.

7단계(종종 가장 긴 단계)의 속도를 높이려면 동적 DNS 레코드의 TTL을 최대한 낮게 설정해야 합니다. 일반적으로 서비스는 90-120초의 간격을 허용합니다. 이것은 완전히 합리적인 타협입니다.

추가

이 모든 작업은 저녁에 구성할 수 있습니다(이미 백업 서버가 있는 경우). okrr 및 동적 DNS 서비스는 모두 무료입니다. oker에서 더 많은 확인을 받고 확인 기간을 단축하려면 프로필 페이지에서 교육을 완료해야 합니다. 완료되면 레벨이 즉시 증가합니다(시간당 지표 20개 + 빠른 1개, 10분). 그리고 그 수가 적다면 다음 주소로 편지를 보내십시오. [이메일 보호], 아마도 증가가 가능할 것입니다 (지금까지 항상 기회가 있었고 거절 한 적이 없으며 반대로 직접 제안했습니다). 처음에는 모든 사람에게 모든 것을 약속하고 싶지 않고 약속을 지킬 만큼 충분한 능력이 있는지 확신할 수 없습니다. 하지만 아직까지는 사용자가 적기 때문에 한도를 높이는 데 문제가 없습니다.

okrr이 일반적으로 할 수 있는 일 - 웹사이트를 살펴보세요 발표. 일반적으로 이는 모니터링(클라우드의 zabbix)이며 파일러는 훌륭한 추가 기능입니다. 등록하지 않고도 사이트에서 데모에 액세스할 수도 있습니다.

표시기 상태가 변경되면 이메일이나 텔레그램으로 알림이 전송됩니다. (무슨 일이 일어나고 있는지 살펴보고 텔레그램이 가장 신뢰할 수 있는 메신저인 것 같다는 것을 깨달았습니다. 스트레스 테스트를 해준 RKN에게 감사드립니다!) okrr이 올바르게 구성되면 모든 알림은 "모든 것을 삭제하세요. 수정해야 합니다!"라는 신호가 됩니다. , 또는 “불이 꺼졌어요!” okerra에서 추가 경고가 있어서는 안 됩니다(있는 경우 어떻게든 다르게 구성해야 합니다). 예를 들어, 고양이 사이트의 경우 알파 서버가 마지막 서버이며 결코 오류를 위장하지 않습니다. 그가 누워 있다면 우리는 알아야 합니다. 그러나 다른 서버는 지속적으로 오류를 가장하므로 한 시간에 여러 번 경고를 받지 않기 위해 해당 표시기는 "자동" 상태입니다.

사과 페이지(모든 기본 및 백업 서버가 다운된 경우)를 포함하거나 okrr의 상태 페이지(예: 당사 서버)로 리디렉션되는 죄송 서버(가장 저렴한 호스팅에서)를 만드는 것도 합리적입니다. cp.okerr.com/status/okerr) 또는 statuspage.io.

출처 : habr.com