소규모 비즈니스를위한 높은 서버 가용성

어느 날 아침에 나타나지 않을 서버에 약간의 두려움이 생겼을 때, 높은업자들은 비즈니스에 고 가용성 / 페일 오버 설정이 필요하다고 결정했습니다.

우리는 회사를 운영하기 위해 5 개의 메인 서버 (4x Linux, 1x OpenBSD)를 운영해야합니다. 서버 중 3 대는 표준 (파일 / 웹 / 데이터베이스)이며, 4 대는 대부분의 네트워크 라우팅 및 웹 프록시를 처리하고, 5 대는 전화 시스템을 지원하며 비표준 하드웨어를 사용합니다.

상사는 서버 장애에 대한 소요 시간이 30 분 미만이어야한다고 말했습니다.

이 분야에 대한 나의 경험은 존재하지 않습니다 (나는 '프로모션 된 프로그래머 일뿐입니다). 제 질문은 실제로 다음과 같이 요약됩니다.

• 이것은 평균 서버 관리 기술을 가진 사람이 시도해야하는 것입니다. 그렇다면 무엇을 읽고 누구와 이야기해야합니까?

감사.

예산에 해당되는지 확인하기 위해 명시된 "요구 사항"을 이행하는 데 필요한 비용을 설명하기 위해 숫자를 모아서 시작해야한다고 생각합니다. 요구 사항 (페일 오버 클러스터링, "핫 마이그레이션"기능이있는 하이퍼 바이저 등)을 충족하는 데 사용되는 모든 "일반"방법에 익숙하지 않은 경우 다음을 수행 할 수있는 컨설턴트를 찾는 것이 좋습니다. 도와주세요.

타당성 조사와 관련하여 약간의 비용이 발생하지만, 우수한 솔루션이 명시된 요구 사항에 적합하지 않다는 것을 발견하는 데 비용이 훨씬 적게 듭니다 (관리자가 기대를보다 현실적으로 설정해야 함을 의미 함). 요구 사항을 전혀 충족시키지 못하고 그 과정에서 많은 돈을 날려 버리는 반값의 일을하는 데 드는 비용보다 더 많은 돈을 모아야합니다.

상사가 방금 그 숫자를 뽑아 낸 것 같습니다. 아마도 그는 몇 가지 분석을 수행했으며 다양한 시스템의 가동 중지 시간과 관련된 시간당 비용이 얼마인지 알고 있지만 의심합니다. 현실과 관련이없는 하늘의 숫자처럼 들립니다. 모든 시스템에 이러한 종류의 가용성이 필요한 경우 놀라 울 것입니다. 비즈니스를 연구하는 과정에서 기능의 일부만 가동 시간과 내결함성이 있어야한다는 사실을 알게 될 것입니다 (따라서 그러한 솔루션은 궁극적으로 비용이 적게 듭니다). 전화와 업무용 응용 프로그램이 설치되어 있다고 확신하지만 일부 다른 시스템에서는 다운 타임을 허용 할 수 있습니다.

내 직감에 따르면 가상화 기술을 사용하여 중복 하드웨어 간 가상 시스템 마이그레이션을 기반으로 장애 조치 시스템을 만드는 데 도움이 될 것입니다. 예산에 맞는지 여부는 비즈니스에 따라 달라집니다. 효과적으로 작동하려면 SAN 유형이 반드시 필요하기 때문입니다.

"전통적인"장애 조치 클러스터링을 할인하지 마십시오. 응용 프로그램이 이러한 구성에 적합하면 확실히 "승리"가 있습니다.

당신의 상사가 치명적인 실패 시나리오 (화상, 홍수, 토네이도, 도난 등)에 대해 생각했는지 궁금합니다. 아직 계획되지 않은 경우 이는 일반적인 비즈니스 연속성 계획 및 재해 복구 우발 상황에서 작동 할 수있는 황금 기회입니다.

귀하의 비즈니스를 연구하고 추천 할 수있는 누군가로부터 도움을 받으십시오. 후회하지 않을 것입니다.

"이 길은 많은 고통과 상처로 이어집니다 ..."

그렇다면 비즈니스 연속성 계획은 무엇입니까? 재해 복구 계획이 있습니까?

토론 했어? 작성 했습니까? 테스트를 받았습니까?

"고급 조직"과 적절한 대화를 나누고 서비스마다 다르기 때문에 고 가용성 요구 사항을 충족시켜야합니다.

그래서 그들이 아침에 느낀 "고통 점"은 무엇입니까?

그 것이었다?

• 전화가 작동을 멈췄습니까? 상당히 중대한 (그리고 보이는) 문제. 그리고 그렇습니다-이것은 "솔루션"이 필요하지만 지원 계약하에 있기를 바랍니다.
• 웹 사이트가 실패 했습니까? 확인-상당히 눈에 잘 띄지 만 예기치 않은 것은 아니며 거대한 웹 사이트가 없다면 그렇게 중요하지 않습니다. 이 서버를 몇 시간 동안 다운 시키십시오.
• 데이터베이스 서버가 다운 되었습니까? 무서운 ... 좋은 백업이 되셨기를 바랍니다! 데이터를 잃어 버리지 않으면 비즈니스가 실패합니다. 그러나 데이터가 안전하다면 서버는 중요하며 복구 계획이 있어야합니다.
• 파일 및 인쇄 (및 내부 앱 등) 이것은 대부분의 사람들이 PITA이며, 당신이 그것을 고칠 때 아침 앉아서 아무것도하지 않을 것입니다.

주 시스템에 고품질 하드웨어를 구입했다고 가정하십니까? 좋은 점은, 하드웨어를 저렴하게 구매하는 것은이 서버가 상자에 모든 것을 "이중"으로 제공하기 때문에 잘못된 경제입니다.

또한 서버를 재구성하고, 팬을 교체하고, 전원 공급 장치를, 서버를 랙에 연결하고, 이중 경로 네트워크를 중복 스위치로 구성하는 방법을 알고 있다고 가정합니다. 무엇이 효과적이고 무엇이 효과가 없는지, 무엇이 정상이며 무엇이 잘못되었는지 이해하기에 충분한 시간을 보냈습니다. 그렇지 않다면 도움과 훈련 (또는 최소한 연습과 경험)을 받으십시오.

아마도 많은 문제가 두려움이었을 것입니다. 그들은 그러한 문제가 발생할 수 있다는 단서가 없었으며 (그리고 서버가 비즈니스에 얼마나 중요한지) 실제로 무엇을하고 있는지 알지 못했습니까 (?) 신뢰 문제?

매우 비싼 HA 경로를 내려 가기 전에 위의 모든 것을 올바르게 가져와야합니다. 사업체가이 비싼 장비를 감당할 수 있는가? (그리고 정의에 따르면 대부분의 경우 고장시에만 사용되며 종종 사용되지 않을 것입니다!)

Evan은 몇 가지 좋은 점에 부딪 쳤지 만, 여기에는 실패에 대비하여 1 시간 미만의 복구 시간을 얻는 특정한 비용 효율적인 방법이 있습니다.

소규모 비즈니스는 소규모 하드웨어를 의미 할 수 있으므로 문제에 직면 할 때 실제로 상당한 양의 복원력을 추가하는 간단한 작업을 수행하는 데 많은 비용이 들지 않을 수 있습니다. 주요 아이디어는 추가 하드웨어를 준비하는 것입니다.

먼저 가상 IP에 대한 생각에 익숙해 지십시오. 이는 사용자가 대화 할 수있는 IP 주소이지만 사용자가 제공 한 서버에 상주 할 수 있습니다. 이것은 사용자의 IP 주소이며 응용 프로그램은 대화를 원할 것입니다. 그리고 그것은 당신이 원하는 모든 솔루션에 대해 가장 도움이 될 것입니다. VIP가 있으면 장애 조치시 응용 프로그램을 다시 구성 할 필요가 없습니다. 또한 중복 하드웨어가 있으면 1 대신 2 개의 구성 업데이트를 수행하여 관리 오버 헤드가 증가하는 영향을 미칩니다.

라우팅 / 웹 프록시 서버로 시작하면 상자 자체에 저장 해야하는 실제 상태가 아니기 때문에 가장 쉬운 방법 일 것입니다. 따라서 동일한 상자를 복제하여 동일하게 구성하십시오. LAN 세그먼트에 둘 다 연결되어 있고 인터넷이 다른 인터페이스에 있다고 가정하고 케이블이 고장난 경우 케이블을 교체하십시오. 라우팅 관점에서 모든 LAN 클라이언트는 기본 경로에 대해 .1 주소 (VIP)를 대상으로 설정하고 프록시 서버는 서버 A에 .2 주소를, 서버 B에 .3 주소를 제공합니다. 이 방법으로 구성 업데이트를 위해 둘 다 관리 할 수 ​​있습니다 (둘 다 적용). 그리고 장애 조치를 수행하기 위해해야 ​​할 일은 .2에서 .1 IP 할당을 제거하고 .3으로 옮기고 인터넷 연결을 다른 인터페이스로 옮기는 것입니다. 매우 복잡하지 않고, 이해하기 쉽고, 두 번째 상자의 추가 하드웨어 비용이 발생합니다. 인터넷 쪽에서 중복성을 얻을 수 있다면 약간의 복잡성을 추가하고 VRRP와 같은 것을 사용하여 자동 장애 조치를 얻을 수 있습니다.

세부 사항이 없으면 말하기가 어렵지만 웹 서버는 간단 할 수 있습니다. 동일한 구성으로 두 번째 서버를 추가하고 두 서버 사이에 vIP를 생성 한 다음 VIP가 실패한 경우 백업으로 VIP를 이동하십시오. 일반적으로 장애 조치에서 세션 상태가 손실되는지는 신경 쓰지 않습니다 (장애 조치를 일으키는 중요한 문제입니다). 따라서 사용자가 다시 로그인해야한다면 별다른 문제가 없습니다. 다시, vrrp는 자동 장애 조치에 사용될 수 있습니다.

DB로 넘어 가면 훨씬 더 복잡합니다. 대부분의 DB에는 일종의 기본 / 보조 모델이 있는데, 여기서 원본 DB를 보조에 백업 한 다음 모든 트랜잭션 로그 또는 DB 변경 사항을 보조에 복사합니다. 다시, 실제로 DB에 액세스하는 응용 프로그램 / 사용자에 대해 VIP와 이것을 결합 할 수 있습니다. 그러나 장애 조치가 더 복잡합니다. 기본의 장애에 따라 실제로 트랜잭션 로그를 복사하고 남게하려면 드라이브를 실제로 시작해야합니다. 그런 다음 보조를 활성화하십시오. 손실 된 일부 데이터를 허용 할 수 있으면 보조 활성을 즉시 가져올 수 있습니다. 장애 조치 후 서버 B는 이제 기본 서버이며 서버 A를 복원하고 새 백업으로 전환하여 서버 b에 문제가 발생했을 때 실패 할 수 있습니다.

파일 서버는 항상 가장 어려운 부분입니다. DB와 달리 파일 시스템의 내장 기능을 얻는 것이 훨씬 어렵습니다. 그러나 두 번째 서버를 사용하면 파일 시스템에서 변경 사항을 검색하고 새 파일을 보조 파일로 복사하는 스크립트를 간단하게 작성하여 일정 수준의 복원력을 얻을 수 있습니다. 기본적 으로이 작업을 수행하는 cron에서 rsync를 실행할 수 있습니다. 다시 한 번, 사용자에게 제공하는 VIP를 사용하고 장애 조치를 수행 할 때 이전합니다. 스크립트에서는 파일을 전송하기 전에 시스템이 VIP의 소유자인지 확인하는 것이 좋습니다. 실제로 rsync가 잘못된 방향으로 실행되고 사용자가 변경 한 내용을 덮어 쓰지 않으려 고합니다. 파일이 실패하면 일부 파일이 손실 될 수 있습니다.

전화 시스템에 대해 무엇을 할 수 있을지 모르겠습니다. 공급 업체와 설정 방법에 따라 다릅니다. 공급 업체는 탄력성을 위해 기성품 솔루션을 보유하고있을 수 있습니다.

마지막 경고 단어. 사용할 설정을 철저히 테스트하십시오. 중요한 정보를 잃지 않고 장애 조치 방법을 알고 있어야합니다. 필요할 때 작동하는지 테스트 테스트 테스트. 구성 변경, 소프트웨어 업데이트 등이 기본 및 백업 모두에 올바르게 적용되는 프로세스가 있는지 확인하십시오. 좋은 소식은 서버를 업그레이드 할 때 장애 조치를 제어 할 수 있다는 것입니다. 액티브-액티브 설정이 아니기 때문에 보조 서버가 필요할 때 보조 서버가 작동하는지 알 수 없습니다.

저는 텔레콤에서 일하고 있으며 대부분의 경우 지리적 그래픽 리던던시를 포함하여 장비가 매우 중복되어 있습니다. 우리의 첫 번째 실패 지점은 변경 후 중복이 테스트되지 않으며 사용자가 중복 모델의 작동 방식을 모르는 변경을 수행한다는 것입니다. 그러나 모든 장비가 몇 초 안에 자동 장애 조치를 지원해야한다는 추가 문제가 있습니다. 30-60 분 이내에 시작 및 실행해야하는 경우 장애 조치시 수동 개입을 허용 할 수 있습니다. 준비 만하면됩니다. 행운을 빕니다.

다른 사람들의 요점은 훌륭하므로 몇 가지 의견입니다.

특히 모든 것을 위해 30 분을 보장하는 것은 불가능합니다. 목표는 말할 수 있지만 항상 X 요소가 있기 때문에 보장 할 수있는 방법이 없습니다. ISP 라인이 2 개있을 수 있고 트럭이 건물에 충돌하고 건물의 반대쪽 끝에서 라우팅되는 것이 중요하지 않다고 생각했기 때문에 둘 다 꺼냅니다.

원가 계산의 시작으로 모든 것을 두 배로 늘리십시오. 5 대의 서버가 있으므로이를 두 배로 늘려야합니다. 모두 하드웨어에있을 필요는 없으며 가상화 할 수는 있지만 내 뜻을 알 수 있습니다. 또한 모든 것이 HA를 인식해야하며 비용이 추가 될 수 있습니다. 라우터를 새 것으로 교체해야 할 경우 2 개가 필요합니다. 전력 회사가 30 분 이내에 백업 될 것이라고 보장 할 수 없으므로 전력 공급을 두 배로 늘리고 발전기를 확보하는 것을 잊지 마십시오.

이 예제는 다소 상쾌한 대기 설정을 생각하고 있는데, 이는 상사가 생각하는 것입니다.

소기업에 대해 더 나은 점은 모든 것을 복구하고 분류 할 계획을 세우는 것입니다.

어떤 서비스가 있는지 파악

중요 (사업 중지)

중요 (비즈니스 속도 저하)

일상적인 일 (비즈니스는 잠시 동안 할 수있는 일).

예를 들어, 콜센터 전화는 치명적이므로 하나는 두 번째 서버와 두 번째 ISP를 구입할 가치가 있고 평균 정전은 약 15 분이므로 UPS는 60 분 동안 지속될 것입니다. 워크 스테이션도 잊어라). 이제 ERP가 중요하다고 말하면, ERP 없이도 기능을 수행 할 수 있습니다. 콜센터 직원이 사용할 수도 있지만 다운 된 경우 펜과 종이 또는 메모장으로 되 돌린 후 ERP를 업데이트 할 수 있습니다. 다운 된 경우이를 수행하는 절차가 더 저렴하여 중요한 서비스로 만들려고 할 수 있습니다. 그리고 일상적인 프린터는 프린터와 같은 것일 수 있습니다. 고통 스럽지만, 모두 다운되면 며칠 동안 마감 할 수 있습니다.

s ** t가 언젠가 팬을 때리는 경우 물건을 고치라는 명령을 내립니다. :)

가능합니까? 확실한. 저렴한가요? 아마도 "소규모 기업"에게는 적합하지 않을 것입니다. 특히 당신에게 일할 수있는 임의의 숫자를 제공하는 보스가 있고 대리 프로그래머로 구성된 IT 부서에서 높은 가용성을 요구하는 경우 (다른 곳에서 여러 번 보았지만 결코 그렇지 않습니다) 상황이 자신의 상황과 같으면 스트레스 수준에 적합합니다).

페일 오버는 가능하지만 일반적으로 서버간에 데이터를 공유하기 위해 여분의 하드웨어, SAN이 필요합니다. 다시 말해, 관리를 담당하는 전담 관리자를 고용하지 않으면 자금을 조달하는 것이 좋습니다.

언급 한 콜 시스템 하드웨어는 특수 하드웨어이며 콜센터라고 언급했습니다. 중복을 만드는 옵션에 대해서는 공급 업체에 문의해야합니다. 그것으로 구르는 것은 처음에는 지원을 무효화 할 수 있습니다.

다른 시스템은 VMWare 유형 솔루션 (또는 Hyper-V 또는 XenServer에 투자하면 중복성을 얻을 수 있지만 VMware와 XenServer를 먼저 살펴 봅니다). 그런 다음 빠른 네트워크 스위치가있는 몇 가지 강력한 서버 인 SAN을 살펴보고 장애가있는 경우 LiveMotion을 사용하여 하드웨어 서버간에 가상화 된 서버를 마이그레이션하고 필요에 따라 서버 간의로드 균형을 조정할 수 있습니다.

해당 시스템에서 Linux를 실행한다고 언급했습니다. 여러 서버를 구입할 돈이 있다면 대신 하트 비트 프로그램과 STONITH를 사용하여 DRBD를 설정하여 서버간에 데이터를 복제하고 서버를 사용할 수 없게되면이를 인수 할 수 있습니다. 문자 그대로 각 서버를 복제 한 시스템을 설정하고 서버 룸 (서버 룸이있는 경우)에서 전력 소비와 열 분산을 두 배로 늘 렸습니다. 그것은 하드웨어 비용과 정신 건강을 위해 할 수 있습니다. 또한 테스트해야하고 구성하는 동안 가동 중지 시간이 발생하며 여전히 잘 려야 할 문제가 발생할 가능성이 있기 때문에 때때로 작동하지 않을 가능성이 있습니다 (분할) 예를 들어 뇌).

마지막은 몇 개의 시스템이 빈 슬레이트 시스템으로 작동하도록하는 계획이며 서버가 죽으면 "빈"시스템 중 하나로 데이터를 복원 할 수있는 백업 계획이 정말 좋습니다. 현장에 하드웨어가 있으면 서버가 죽을 때 / 일부 옵션이 제공됩니다. 그러나 데이터를 복원하는 동안 여전히 다운 타임이 발생하므로 응용 프로그램을 새 서버에 올바르게 설치하는 방법에 대한 지침이 필요합니다. 작업 속도와 데이터 용량에 따라 가동 중지 시간이 몇 시간에서 하루 또는 이틀 정도 지속될 수 있습니다. 당신은 할 그래, 장소에 복구 계획하여 서버에 대한 작업 알려진 좋은 백업을 가지고?

시도해야합니까? 내 첫 번째 반응은 당신이 어떤 제안에서 머리를 긁거나이 물건을 생각하려고 할 때 뱃속에 구덩이를 느끼면 안된다는 것입니다. 문제를보고 비용을 해결하고 구현하려면 컨설팅 회사가 필요하거나 회사를 위해 전담 시스템 관리자를 고용해야합니다.

그들이 당신에게 그것을하고 있다고 말하고 당신은 당신이 "승진 된"프로그래머이고 당신은 최대 30 분의 실패 시간으로 중복성을 주도록 PHB가 당신이 친절하다는 것을 말하고 있습니다 개울의.