오픈 소스 고 가용성을 사용하는 경우 팀에 필요한 7 가지 기술

고 가용성 (HA) 영역에는 오픈 소스 경로로 이동하기로 결정한 경우 팀에 필요한 특정 중요한 기술이 있습니다. 정의에 의한 오픈 소스는 자유롭게 사용할 수있는 소프트웨어를 의미합니다.

오늘날 Microsoft 및 SIOS Technology Corp와 같은 공급 업체에서 제공하는 많은 운영 체제에 대한 고 가용성 클러스터의 상용 구현이 많이 있습니다. 이러한 상용 솔루션은 리소스 모니터링, 종속성 관리, 장애 조치 및 클러스터 정책, 그리고 사전 패키지 및 가격이 책정 된 관리 형태를 제공합니다.상업적 구현에 대한 대안은 기업에 고 가용성을 제공 할 수있는 기회를 기업에 제공하는 몇 가지 오픈 소스 옵션입니다.

기업들이 계속해서 최적화, 비용 절감 및 더 엄격한 통제를 추구함에 따라 점점 더 많은 기업과 고객이 오픈 소스 가용성 솔루션으로의 전환을 고려하고 있습니다.

다음은 팀이 오픈 소스 HA로 전환하는 데 필요할 수있는 7 가지 기술입니다.

1. 코딩 기술

대부분의 경우 엔터프라이즈 애플리케이션에 대한 사전 패키지 및 번들 지원이 없다는 것은 팀이 구성 요소를 보호하고 번들 구성 요소로 문제를 해결하거나 애플리케이션 인식이 제대로 처리되도록 애플리케이션 커넥터를 작성하는 솔루션을 개발할 수 있어야한다는 것을 의미합니다.많은 사람들이 스크립트를 작성할 수 있지만 팀은 건전한 개발 관행과 표준을 만들고 준수하는 방법을 알아야합니다.이것의 기본은 다음과 같습니다.

• 설계 및 아키텍처 요구 사항
• 디자인 리뷰
• 코드 / 코드 검토 및 단위 테스트 (가급적 자동화)

2. 기술 환경에 대한 지식

많은 엔터프라이즈 응용 프로그램은 SLA (서비스 수준 계약) 및 SLO (서비스 수준 목표)를 충족하는 고 가용성을 제공하기 위해 여러 시스템과의 통합이 필요합니다.팀은 여러 엔터프라이즈 시스템과의 통합을위한 보호 및 솔루션을 구축하기 위해 기술 환경에 대한 심층적 인 애플리케이션 인식과 지식이 필요합니다.중요한 응용 프로그램, 해당 응용 프로그램의 기술 환경, 네트워킹, 하드웨어, 하이퍼 바이저, 환경 및 응용 프로그램 종속성을 이해하는 사람이 필요합니다.또한 오픈 소스 커뮤니티에서 사용하려는 HA 기술 집합의 아키텍처, 기능 및 제한 사항을 이해하는 팀 구성원이 필요합니다. 팀이 다음 영역을 얼마나 알고 이해하는지 고려하십시오.

• 데이터 전달 및 노드 통신
• 노드 실패
• 응용 관리
• 시스템 복구 및 다시 시작
• 로깅 및 메시지
• 데이터 복원력 및 보호

3. 비즈니스 프로세스 지식

비즈니스 요구 사항과 비즈니스 프로세스를 이해할 수있는 사람이 필요합니다.팀에는 기업의 비즈니스와이를 추진하는 프로세스를 이해하는 전문가가 필요합니다.팀은 솔루션 개발에 사용할 수있는 예산의 양, 비즈니스가 감수 할 수있는 위험의 정도, 말하지 않거나 지정되지 않은 추가 요구 사항을 수집하는 방법을 알고 이해해야합니다.

또한 팀은 이러한 비즈니스 요구 사항을 소프트웨어 요구 사항으로 변환하는 방법과 비즈니스 요구 사항을 충족하는 최소 실행 가능한 고 가용성 솔루션을 실현하는 프로세스를 관리하는 방법을 알고 있거나이를 고용해야합니다. 비즈니스 프로세스에 적합합니다.

4. OS, 애플리케이션 및 인프라 경험

모든 것을 개방하려는 경우 팀은 운영 체제, 애플리케이션 및 인프라를 이해 한 경험이 필요합니다.Linux 용 커널 버전, Windows 용 업데이트 및 핫픽스를 포함하여 다양한 OS 출시주기를 이해해야합니다.지원해야하는 애플리케이션이 사내에 있지만 애플리케이션 업데이트주기, 종속성, 애플리케이션과 OS 지원 매트릭스의 교차점을 이해하기 위해 부지런히 노력해야합니다.환경이 균질하다면 훌륭합니다.그렇지 않으면 팀이 RHEL, RHEL 파생 제품 및 SUSE의 차이점을 알아야합니다.Linux와 Windows 모두라면 이것도 알아야합니다.또한 인프라가 애플리케이션과 OS 조합에 미치는 차이를 이해해야합니다.AWS 및 Azure는 GCP, 온 프레미스 및 기타 하이퍼 바이저와 다른 고 가용성의 차이점을 나타냅니다.

5. 변경 관리 기능

OS, 인프라 및 애플리케이션에 대한 확고한 이해와 함께 기술 및 비즈니스 지식을 갖춘 솔루션을 개발할 개발 팀이 있다고 상상해보십시오.그러나 스크립트를 모으는 것은 시작에 불과합니다.팀에도 변경 관리 기능이 필요합니다.팀은 코드 변경 및 버전, 패키지 및 패키지 위치를 어떻게 추적합니까?팀은 업데이트 및 변경 릴리스를 어떻게 관리합니까?팀은 git과 같은 소스 리포지토리, Jira와 같은 프로젝트 관리 도구 및 릴리스 교육 숙련도에 정통해야합니다.원치 않는 영향을 피하면서 코드를 업데이트하고 패치 및 수정을 제공하는 방법을 이해하는 팀이 필요합니다.

6. 데이터 분석 및 문제 해결 경험

자체 HA 솔루션을 제공하는 공간에 들어가면 팀은 분석 및 문제 해결 경험이 필요합니다.애플리케이션 코드, 시스템 메시지, 애플리케이션 오류 로그 및 추적 파일의 교차점을 이해하는 리소스가 필요합니다.시스템 충돌이 발생하면 로그를 더 자세히 조사하여 문제를 해결하고 근본 원인을 찾고 데이터를 분석하여 권장 사항을 만들고 변경 사항을 배포 할 준비를해야합니다 (위의 # 5 참조).또한 팀은 오류, 실패 또는 시스템 충돌이없는 경우에도 이러한 로그 및 추적 파일의 데이터가 환경 상태에 대해 알려줄 수있는 데이터를 알고 이해해야합니다.

7. 연결 (개발자, QA, 파트너, 커뮤니티)

솔직히 말해서 여러분의 비즈니스는 고 가용성을 제공하는 것이 아니라 오픈 소스 HA 영역에 뛰어 들기로 결정한 경우 팀의 뛰어난 능력보다 더 많은 도움이 필요할 것입니다.추가 도움을 얻는 열쇠는 어디서부터 시작해야하는지 이해 한 다음 커뮤니티 개발자, 테스트 전문가, HA 및 애플리케이션 파트너, 오픈 소스 커뮤니티와 올바른 연결을 만드는 것입니다.공개 포럼은 정말 도움이되었지만 응답 시간이 SLA 및 SLO를 준수하는지 다시 확인해야합니다.

오픈 소스 솔루션을 사용하는 것은 많은 기업이 비용 문제와 유연성, 비용 절감 및 위험 감소에 대한 인식을 추구하기 위해 선택하는 옵션입니다.그러나 구매자는 새로운 기술 및 관리의 형태로 숨겨진 비용이있을 수 있으며 사용하는 오픈 소스 프로그램의 관점에서 "자신의 HA 솔루션 롤"에 필요한 숨겨진 위험이있을 수 있습니다.

– Cassius Rhue, VP, 고객 경험

SIOS에서 재현

2020 년에는 더 많은 기업이 미션 크리티컬 애플리케이션, ERP 및 데이터베이스를 클라우드로 마이그레이션하는 것을 보았습니다. 그러나 이러한 모든 마이그레이션이 순조롭게 진행되지는 않았습니다. 저는 개인적으로 클라우드 마이그레이션 프로젝트가 애플리케이션 가용성에 대한 계획 부족, 'DIY 고 가용성'개조의 복잡성, '리프트 앤 시프트'가 수반하는 것과 관련된 오해 및 예상치 못한 비용으로 인해 급격히 느려지고 중단되는 것을 목격했습니다.

조직이 클라우드를 준비 할 수있는 다양한 모범 사례, 클라우드 체크리스트 및 기타 방법이 있습니다. 다음 모범 사례는 2020 년 클라우드 마이그레이션을 중단했거나 2021 년에 진행할 계획 인 사람들을 위해 고 가용성 클러스터링을위한 모든 마이그레이션 전략에 고려되어야합니다.

클라우드 마이그레이션 모범 사례

요구 사항 수집

클라우드로 이동하는 많은 조직은 클라우드가 클라우드로 이동 한 온 프레미스 아키텍처라고 생각합니다. 클라우드 마이그레이션에 대한 이러한 오해로 인해 네트워킹, 스토리지, 디스크 속도 및 온 프레미스의 시스템 크기가 클라우드 현실과 충돌 할 때 종종 지연 및 지연이 발생합니다. 클라우드로의 원활한 전환은 인프라, 거버넌스 및 규정 준수, 보안, 크기 조정 및 관련 제어 및 리소스에 대한 실제 요구 사항을 수집하는 것으로 시작됩니다.

디자인 및 문서

설계 단계에서 온 프레미스 환경의 아키텍처는 최대 가용성을 위해 선택되고 철저하게 문서화 된 클라우드 환경에 매핑됩니다. 이 단계에서 아키텍처가 형성되고 IP,로드 밸런서, IOPS 및 데이터 가용성에 대한 전략을 식별합니다. 팀은 클라우드의 복잡성을 자동화 할 수있는 강력한 애플리케이션 및 인프라 가용성 솔루션으로 클라우드 고유의 가용성을 어떻게 강화해야하는지 살펴 봐야합니다. SIOS에서 AWS 및 Azure 클러스터링 및 가용성 전문가는 고객과 협력하여 AWS EFS, Azure ANF 또는 독립 실행 형 NFS 클러스터 계층에 대한 온 프레미스 NFS를 교체합니다. 또한이 단계에서 성공적인 구현의 핵심 부분은 모든 것을 문서화하는 것입니다. 문서화는 종종 무시되지만 마이그레이션 성공의 필수 요소입니다.

고 가용성 계획

클라우드에서 고 가용성을 달성하려면 요구 사항을 이해하고, 설계를 만들고, 이러한 요구 사항을 달성하기위한 전략을 세우는 계획을 문서화해야합니다. 기본 계획에는 인력 배치, 직원 교육, QA 시스템 테스트 배포, 사전 프로덕션 단계, 배포, 배포 후 유효성 검사 및 지속적인 반복이 포함되어야합니다. 클라우드 마이그레이션의 최상의 결과는 계획된 계획된 프로세스에서 비롯됩니다. 임시 고장 수리 접근 방식이 아닙니다.

직원

귀하의 팀은 클라우드 마이그레이션을 위해 얼마나 잘 인력을 배치하고 있습니까? 기존 헬프 데스크, 클라이언트 / 서버 IT 또는 IT 팀은 클라우드 마이그레이션에 충분하지 않을 수 있습니다. 팀이 클라우드를 처음 접하는 경우 더 많은 리소스 또는 전문 서비스 기반 솔루션을 추가하는 것을 고려할 때입니다. 클라우드로의 마이그레이션은 적절한 통찰력, 정보 또는 교육 없이는 부담스럽고 지루하며 어려울 수 있습니다. 직원이 클라우드 환경과 관련된 교육을 통합해야합니까? IT 팀을 지원하기위한 교육 및 전문 서비스를 찾고있는 동안 공급 업체에 가용성 솔루션과 관련된 교육을 문의하십시오. 많은 공급 업체가 HA 솔루션에 대한 유연한 교육을 제공하며 클라우드 공급 업체 또는 Udemy와 같은 인기 사이트에서 클라우드 교육을받을 수 있습니다.

QA 배포

QA 배포 단계는 팀이 실제 시스템을 클라우드에 배포하기위한 계획을 실행하는 단계입니다. 성공적인 배포 팀은 계획과 전략을 검증하고, 데이터 마이그레이션 프로세스를 이해하고, 누락 된 종속성을 발견하고, 프로세스의 다음 단계, 특히 테스트를 준비합니다. 이 단계를 건너 뛰거나 생략하면 한때 약속했던 마이그레이션이 종종 중단되거나 실패합니다. QA 시스템 배포 단계에 도달하면 팀은 클라우드에서 애플리케이션, 데이터베이스 및 중요 데이터의 초기 마이그레이션 및 구성에 대한 무거운 작업을 수행합니다.

고 가용성 테스트

QA 환경에서 테스트하는 것은 중요한 단계입니다. 이러한 테스트는 시간 낭비가 아닙니다. 시간을 절약 할 수 있습니다. 클라우드에 환경을 배포하는 것이 온 프레미스 배포보다 더 쉬운 경우가 많습니다. QA 환경은 Ansible과 같은 도구를 사용하여 스크립팅하거나, 클라우드 마켓 플레이스 또는 복제 된 이미지의 템플릿으로 빠르게 배포하거나, 클라우드 형성 템플릿에서 배포 및 구축 할 수 있습니다. 일단 배포되면 재난 시나리오는 재난이 아닌 재난 이전에 정리하고 최적화 할 수 있습니다. 테스트 시나리오를 활용하여 네트워킹 또는 디스크 속도와 관련된 오버 프로비저닝, 언더 프로비저닝 또는 병목 현상을 식별 할 수 있습니다. 새로운 직원을위한 온 보딩 전략의 일부로 전체 테스트 시나리오를 사용할 수도 있습니다. 또한 스냅 샷 및 백업에 대해서도 테스트를 수행해야합니다.

프로덕션 배포

테스트 단계가 완료되고 팀이 테스트 결과를 검증하면 다음 단계는 QA에서 사전 프로덕션으로, 사전 프로덕션에서 가동으로 이동하는 것입니다. 테스트 단계는 최종 사용자 승인 테스트, 프로덕션 데이터의 최종 전환 및 업데이트, 그리고 사용자를 포함하는 무거운 작업의 마지막 단계입니다.

검토, 수정 및 반복

성공적인 마이그레이션은 가동 단계에 도달해도 끝나지 않고 수명주기 단계를 통해 계속됩니다. 클라우드 마이그레이션 전략의 사후 가동 단계에서 팀은 '수집'에서 '생산 배포'까지의 단계를 계속 검토, 수정 및 반복합니다. 실제로 팀은 릴리스, 애플리케이션 업데이트, 보안 업데이트, 관련 시스템 유지 관리, 운영 체제 버전, 재해 복구 계획 및 고 가용성 공급 업체의 최고 요구 사항에 대한 요구 사항을 기반으로이 프로세스를 반복해야합니다. 관행. 클라우드 플랫폼은 항상 진화하고 있으며 기존 HA 솔루션 및 아키텍처를 향상시킬 수있는 새로운 기능, 업데이트를 추가합니다. 프로세스를 검토, 수정 및 반복하는 것은 성공적인 온 보딩에 필요한 단계입니다.

2021 년에는 더 많은 기업이 더 많은 미션 크리티컬 애플리케이션, ERP 및 데이터베이스를 클라우드로 마이그레이션 할 것입니다. 성공의 주요 주요 요인은 클라우드 마이그레이션 모범 사례를 활용하여 프로세스 전반에 걸쳐 지연 및 실패를 방지하는 것입니다. 비즈니스 요구 사항 및 요구 사항을 이해하고, 설계 및 계획을 문서화하고, 특정 목적으로 구축 된 클러스터링 솔루션을 사용하여 QA 환경에 배포하고, 가동 전에 광범위한 테스트를 실행하는 것이 필수적입니다. 신중한 클라우드 이전 권장 사항에 SIOS Protection Suite를 포함하는 방법을 알아 보려면 SIOS Technology에 문의하세요.

-Cassius Rhue, VP, 고객 경험

SIOS에서 재현

고 가용성 서버 솔루션을 구축하는 방법은 무엇입니까?

고 가용성 솔루션의 핵심 구성 요소는 클라이언트 트래픽을 리디렉션하는 방법을 파악하는 것입니다. 거의 모든 사용자 기반 애플리케이션은 서버에 연결해야합니다. 클라이언트 트래픽을 리디렉션하면 사용자는 응용 프로그램이나 데이터베이스가 실제로 어디에 있는지 알 필요없이 연결할 수 있습니다.

대부분의 솔루션은 네트워크 기반 IP 리디렉션 또는 네트워크 기반 DNS 리디렉션을 권장합니다. 작동합니다. 그러나 경험상 고 가용성 서버를위한 최상의 솔루션은 한 서버에서 다른 서버로 전환 할 수있는 가상 IP 주소를 사용하는 것입니다. 서버는 현재 한 서버에서 호스팅되고 다른 날에는 다른 서버로 전환되는 가상 IP 주소의 연결을 수신합니다.

한 단계 더 나아 가기 위해 장애 조치를 자동화 할 수 있습니다. 여기에서 오류가 감지되면 시스템이 결정을 내리고 애플리케이션을 전환합니다. 이 단계는 고 가용성 솔루션을 구축하는 데 중요합니다.

구매 및 고 가용성 솔루션 구축의 이점

이것은 스크립트와 로직을 사용하여 한 서버에서 다른 서버로의 프로세스 상태와 가상 IP 주소를 확인하는 것을 구현할 수 있습니다. 그러나 구매 대 고 가용성 솔루션 구축에서 우리가 직면하는 과제 중 하나는 구축에 실제로 얼마나 많은 시간을 소비해야 하는가입니다. 여기에는 스크립트 코딩, cloudwatch API 또는 람다 함수와 같은 API 개발 시간이 포함됩니다. 테스트와 유지 보수를 잊지 말자.

제가 어렸을 때 저는 그 코드를 작성하고 싶었습니다. 하지만 Fortune 100 대 기업에서 일하고 고위 관리자에게 소리를 지르고 오전 3시에 스크립트 중 하나가 작동하지 않았을 때 느낌이 다릅니다. 이 문제는 내가 1 년 전에 작성한 코드에 대한 문제를 발견했을 때 더욱 악화되었습니다. 관리자들은 고 가용성 솔루션이 100 % 작동하기를 원했습니다. 작동하지 않으면 누군가에게 전화를 걸어 소리를지를 시간입니다.

SIOS는 고 가용성을 자동화합니다

장기적으로 솔루션을 구입하고 설정에 맞게 조정하는 데 약간의 시간을 투자하는 것이 더 저렴하지 않습니까? 애플리케이션이나 데이터베이스에 관계없이 SIOS 고 가용성 (HA) 솔루션이 여기에서 제공됩니다. SIOS에는 한 서버에서 다른 서버로 프로세스 스택을 전환하는 코드가 있습니다. 이를 통해 사용자와 관리자는 장애 조치 오케스트레이션과 고 가용성을 자동화하여 안심할 수 있습니다.

내가 SIOS HA 우산에 대해 좋아하는 두 가지가 있습니다. 하나는 IP 주소가 서버에 추가되고 애플리케이션이 연결을 수신하기 위해 다시 시작되는 가상 IP에 대한 코드입니다. 두 번째는 SIOS가 제공하는 애플리케이션에 구애받지 않는 API 세트를 사용하여 활성화됩니다. 이를 통해 누구나 플러그인을 사용하여 모든 애플리케이션을 보호 할 수 있습니다. 환경에 맞는 고 가용성 솔루션에 대해 자세히 알아 보려면 지금 SIOS에 문의하십시오.

– Edmond Melkomian, PMP, MCSD, 컨설턴트, SIOS technology, Inc.

SIOS에서 재현

IT 재해 복구 슬픔의 단계

올바른 엔터프라이즈 가용성 아키텍처를 구현하지 않은 경우 재해 복구에 대한 슬픔이 갑자기 나타날 수 있습니다. IT 분야의 친구 Dave를 만나 재해 슬픔의 5 단계를 안내합니다.

1 단계 : 거부

IT 분야의 Dave :“오 오.그 경고는 무엇입니까?약간의 애플리케이션 충돌 일 뿐이죠?별거 아니야.곧 작업을 시작하고 실행할 수 있습니다.”

엔터프라이즈 가용성의 땅에는 약간의 애플리케이션 충돌이나 큰 문제가 없습니다.회사는 실제 돈으로 SLA를 사용합니다.선택적인 현실은 아마도 고객과 이해 관계자의 관점과 같지 않을 것입니다.

2 단계 : 분노

IT 분야의 Dave :“농담하니?무엇보다도 …[censored] … 때로는 오늘 애플리케이션이 시작되지 않습니다.어.이건 싫어요 [censored]..[censored]. 응용 프로그램.이 새로운 경고는 무엇입니까?이제 데이터 센터가 다운되었습니다!”

빠른 속도와 높은 위험 환경에서 정말, 정말 빠르게 지저분 해집니다. 확인되지 않은 경고 및 실패가 발생하면 압력, 좌절 및 분노와 함께 문제가 빠르게 증가 할 수 있습니다.

상태 3 : 교섭

IT 분야의 Dave :“응용 프로그램 분야의 Ard, 저는 IT 분야의 Dave입니다.App1 환경에 대한 백업이 있습니까? . . . 확실한가요?다시 확인해 주 시겠어요?두 번 확인했지만 한 번 더 확인하실 수 있습니다.화요일에 타코에 음료를 살게요!”

IT 분야의 Dave :“Hey Donna DBA, 저는 IT 분야의 Dave입니다. Art in Applications는 당신이 나를 도울 수 있다고 말했습니다.우연히 해당 재무 데이터베이스 또는 재고 관리 시스템에 대한 데이터베이스 복제를 설정 했습니까? . . . 확실합니까?음, 우리가 umh에서 복구 할 방법이 있는지 기억하십니까? . . 데이터 센터 충돌?”

내 딸이 곤경에 처하면 흥정이 그녀의 첫 번째 행선지입니다.좋아, 두 번째.첫 번째는 사라지는 것이지만 당신은 너무 똑똑해서 불길을 피할 수 없습니다.그러나 IT 분야의 Dave 만 협상과 구걸이 고 가용성 및 재해 복구를 위해 잘 정의 된 전략을 대체 할 수 없다는 사실을 깨닫는 유일한 사람은 아닙니다.“80 %의 사람들이 신경 쓰지 않고 20 %가 당신을 기쁘게 생각합니다 (Les Brown에서 패러 프레이징)”때문에 협상을 건너 뛰고 재난에 대해 구걸합니다.

4 단계 : 슬픔

IT 분야의 Dave :“이건 정말 대단합니다.애플리케이션 서버가 고장 났고 데이터 센터가 다운되었으며 백업을 찾을 수 있고로드 할 수 있다면 복원하는 데 몇 시간이 걸립니다.여기서 벗어날 방법이 없습니다. 업데이트 된 이력서를 어디에 넣었습니까?”

물론 백업이 있고 유효성을 검사했습니다.그러나 이러한 백업으로 돌아 가면 RTO 및 RPO에 미치는 영향이 있습니다.이번에는 흡수 할 수 있습니까?물론 데이터 센터가 복구 된 후입니다.

5 단계 : 수락

IT 분야의 Dave :“2 시간이 지났습니다.나는 우리가 이렇게 많은 경영진이 있다는 것을 몰랐습니다.이 후로 2 주년을 맞이할 수 없습니다.글쎄요, 내일 사무실 청소를 할 것 같아요.나는 이것을 통해 그것을 만들 수 없습니다!”

실패가 발생합니다.데이터 센터가 다운됩니다.응용 프로그램이 실패합니다.데이터 센터 손실, 서버 장애 또는 애플리케이션 충돌 가능성을 부인할 수 없습니다.이러한 유형의 수락은 정상이며 가용성 향상의 일부입니다.가용성 전략을 구현하지 못했기 때문에 직장을 잃거나 더 나빠질 수 있다는 사실을 받아들이는 것은 SIOS Technology Corp.의 전문가가 피하고 싶은 것입니다.

IT 분야에서 Dave처럼되지 마십시오.모니터링, 복구 및 시스템 장애 조치 자동화를위한 최상의 솔루션과 결합 된 최상의 하이브리드, 온 프레미스 또는 클라우드를 포함하는 엔터프라이즈 가용성 아키텍처를 설계하고 구현하여 재해 슬픔 단계, 재해 복구 및 다운 타임 시간을 피하십시오. .

– Cassius Rhue, VP 고객 경험

SIOS에서 재현