자가 복구 로드 밸런싱 서비스 구축

https://blogs.vmware.com/load-balancing/2020/09/23/self-healing-load-balancing-services/

클라우드는 이중화 및 내결함성을 모두 갖추고 있으며, 인프라 개발에서는 장애를 허용하면서도 종종 복원력으로 일반화되는 적절한 서비스 품질을 보장하는 특정 시스템의 기능이 일반적으로 요구 사항으로 지정됩니다. 그러나 어떤 구성 요소도 100% 가동 시간을 보장할 수 없습니다. 아무리 비싼 하드웨어라도 장애가 발생할 수 있고, 정전 시 전체 데이터 센터가 오프라인 상태가 될 수 있으며, 실수로 구성 요소를 잘못 구성하거나 구성 요소를 종료/연결 해제하면 서비스 중단이 발생할 수 있습니다.

이러한 문제의 대부분은 가용성 영역, 재해 복구 DC 및 고가용성 인프라를 갖춘 무장애 네트워크를 설계함으로써 극복할 수 있다. 그러나 99.99%의 유휴 기간 동안 인프라 구성 요소를 구축하여 운영 및 자본 비용이 많이 들지만, 직원들은 유휴 인프라를 유지해야 했지만 여전히 서비스 중단을 보장하지 않습니다. 비용 효율적인 진정한 내결함성 네트워크를 구축하려면 요구 사항에 따라 네트워크를 스케일업/스케일링하고 무언가가 고장 나면 스스로 수정해야 합니다.

VMware NSX Advanced Load Balancer(이전의 Avi Networks)를 사용하면 자동으로 자체 수정하여 제공되는 서비스 가용성에 영향을 주지 않으면서 개별 구성 요소가 실패할 수 있습니다. 예를 들어 eCommerce 공급자인 한 고객이 실수로 Avi Service Engine 세트를 꺼서 오프라인 상태가 되고 NSX ALB의 자동 장애 복구로 인해 며칠 후 다른 이유로 로그를 검토할 때까지 서비스 엔진이 고장났다는 사실을 인식하지 못했습니다.

그렇다면, 그들이 사고로 몇 대의 AVI 서비스 엔진과 연결이 끊겼다는 것을 깨닫지 못한 이유는 무엇일까요? 간단한 대답은 다음과 같습니다. Avi 컨트롤러는 서비스 엔진이 다운된 것을 감지하면 모든 가상 서비스를 충분한 용량의 사용 가능한 서비스 엔진으로 이동하거나 새 서비스 엔진을 회전시킵니다. 또한 Avi 컨트롤러가 서비스 엔진의 리소스 소모가 감지되는 경우에도 마찬가지입니다. 컨트롤러는 증가하는 수요를 수용하기 위해 추가 서비스 엔진을 자동으로 가동하여 최종 사용자의 일관된 환경을 보장할 수 있습니다. 이와는 대조적으로, 기존 로드 밸런싱과 달리 우발적인 연결 끊김 또는 종료는 수요에 따라 자동 상향 및 하향 조정이 없는 것은 말할 것도 없고, 애플리케이션 액세스의 완전한 손실 또는 심각한 서비스 저하로 이어질 수 있습니다.

자동 장애 복구는 세 가지 탐지 방법을 사용합니다.

Controller-to-Service Engine 고장 감지:

모든 배포 모드에서 Avi 컨트롤러는 제어되는 모든 그룹의 모든 서비스 엔진에 하트비트 메시지를 보냅니다. 특정 서비스 엔진에서 6회 연속 하트비트 메시지에 대한 응답이 없는 경우 컨트롤러는 서비스 엔진이 작동 중단된 것으로 결론짓고, 모든 가상 서비스를 충분한 용량의 사용 가능한 서비스 엔진으로 이동하거나 새 서비스 엔진을 회전시킵니다.

Service Engine-to-Service Engine 고장 감지 방법:

위에서 언급한 Controller-to-Service Engine 오류 감지 방법에서 컨트롤러는 관리 인터페이스를 통해 정기적인 하트비트 메시지를 전송하여 서비스 엔진 고장을 감지합니다. 그러나 이 방법은 서비스 엔진의 데이터 인터페이스에 대한 데이터 경로 장애를 감지하지 못합니다. 전체적인 오류 감지를 위해 서비스 엔진은 데이터 인터페이스를 통해 주기적으로 하트비트 메시지를 전송하며, 컨트롤러가 서비스 엔진이 작동 중단된 것으로 결론을 내리면 모든 가상 서비스를 충분한 용량으로 사용 가능한 서비스 엔진으로 이동하거나 새 서비스 엔진을 회전시킵니다.

BGP-Router-to-Service Engine 고장 감지 방법:

BGP가 구성된 경우 서비스 엔진 대 서비스 엔진 고장 감지는 양방향 전달 감지(BFD)에 의해 증강되며, 이는 SE 장애를 감지하고 라우터에 흐름 로드 밸런싱을 위해 실패한 SE로의 경로를 사용하지 않도록 안내하고 BGP 프로토콜 타이머도 사용합니다.

용량 증가 및 재조정

그러나 진정한 복원력을 갖춘 네트워크를 구축하기 위해서는 자동 장애 복구만으로는 충분하지 않으므로 필요한 경우 자동으로 용량을 늘리거나 리소스를 재분배하는 형태로 성능을 해결하는 것이 매우 중요합니다. 애플리케이션 전송 태스크를 수행하는 동안 서비스 엔진에 리소스가 소모될 수 있습니다. 이는 새 애플리케이션의 배포, 높은 CPU 또는 메모리 사용률 또는 트래픽 패턴 때문일 수 있습니다. 서비스 엔진에서 여러 애플리케이션 및 네트워크 원격 측정 기능을 실시간으로 모니터링하여 가상 서비스를 활용도가 낮은 서비스 엔진으로 자동 마이그레이션하거나 다중 지역 및/또는 다중 가용성 영역 배포 환경에 걸쳐 가상 서비스를 확장하여 용량을 늘릴 수 있습니다. 이를 통해 여러 활성 서비스 엔진이 단일 가상 서비스의 워크로드를 동시에 공유할 수 있습니다.

또한 NSX ALB는 애플리케이션 액세스 패턴을 학습하고 학습된 트래픽 패턴 및 애플리케이션 사용량에 따라 지능적이고 예측적인 자동 확장을 수행할 수 있으므로 수요가 서비스 소진 또는 중단을 야기하기 전에 서비스 가용성을 높일 수 있습니다.

자동 부하 분산

NSX ALB를 통해 기업은 여러 클라우드 간에 워크로드를 쉽게 이동할 수 있습니다. NSX ALB를 사용하면 트래픽 피크 시 클라우드에 자동으로 오버플로가 발생하여 AWS/GCP/Azure를 데이터 센터에 자연스럽게 확장할 수 있습니다. NSX ALB는 퍼블릭 클라우드에 애플리케이션 리소스를 자동으로 생성하여 트래픽 급증 현상을 흡수하고 다시 축소할 수 있습니다. 운영 자동화를 위해 NSX ALB는 기본적으로 주변 에코시스템과 통합되어 방화벽이 자동으로 시작, IP 주소 지정 및 DNS를 Infoblox, Amazon RAW 53 등과 함께 자동으로 구성할 수 있지만 REST API를 통해 일부 사용자 지정을 제공할 수도 있습니다.

NSX ALB PULSE – 지원 및 보안을 위한 클라우드 서비스

시스템이 자체 치유되는 반면, VMware NSX ALB PULSE 서비스는 전 세계에 분산된 Avi 컨트롤러 클러스터 세트를 위한 자동화되고 중앙 집중화된 기능을 제공하여 장애의 원인을 파악하기 위한 사후 이벤트 분석을 자동으로 수행할 수 있도록 지원합니다.

클러스터 내의 모든 Avi 컨트롤러는 NSX ALB PULSE 서비스에 연결하여 최신 위협 인텔리전스를 검색하고 시스템 장애가 감지되면 자동으로 VMware 지원팀에 문의할 수 있습니다.

NSX ALB PULSE에서 제공하는 이러한 새로운 서비스는 네트워크 작업의 복잡성, 관리 및 비용을 줄여줍니다. 자동화된 규정 준수 및 문제 해결 서비스를 통해 위험을 줄이고, 비즈니스 민첩성을 향상시키며, 비즈니스의 디지털 혁신을 가속화합니다.

자동화된 지원 사례 관리

대부분의 엔터프라이즈 모니터링 시스템에서는 네트워크 내에서 오류 또는 문제가 발생할 경우 이를 경고합니다. 이 레거시 접근 방식의 과제는 누군가가 실패한 시스템에 로그온하고, 지원 번들을 다운로드하고, 로그 파일 및 추적(여러 시스템에서 점프 박스를 통해서만 액세스할 수 있음)을 다운로드하고, 고객 지원부에 연락하여 사례를 생성하고, 지원 파일을 고객 지원부에 업로드한 다음, 지원을 기다려야 한다는 것입니다.뭐가 잘못됐는지 알아내는 기술자 이 프로세스는 시간이 많이 걸리고 오류가 발생하기 쉽습니다.

NSX ALB PULSE Services에는 이러한 문제를 해결하기 위한 자동화된 지원 사례 관리가 포함되어 있어 운영자는 장애가 발생할 경우 지원 사례를 자동으로 생성할 수 있습니다.

오류 통보 시 관리자는 클러스터 내의 모든 컨트롤러에서 직접 지원 사례를 생성하기만 하면 됩니다. 선정된 컨트롤러는 소프트웨어 버전, 연결된 서비스 엔진 등 생태계 메타 데이터를 모두 수집하고 로그와 추적을 모두 갖춘 기술 지원 번들을 만들어 자동으로 기술 지원 사례를 만들고 수집된 메타 데이터에서 모든 정보를 작성하고 기술 지원 번들을 만든 사례에 업로드한다. 따라서 모든 관련 정보가 포함된 지원 사례를 생성하는 데 걸리는 시간이 몇 시간에서 몇 분으로 단축됩니다.

또는 NSX ALB PULSE 자동 사례 생성을 통해 장애가 발생할 경우 클러스터 내의 모든 컨트롤러가 관리자의 개입 없이 모든 에코 시스템 메타데이터를 수집하고 기술 지원 번들을 생성하며 기술 지원 사례를 자동으로 생성합니다. 사례 생성 시 VMware 기술 지원부에서 즉시 사례 작업을 시작하고 고객에게 솔루션을 통해 통지합니다.

NSX ALB는 매우 안정적인 분산 클라우드 아키텍처를 제공하지만 개별 구성 요소가 실패할 경우 시스템에서 제공하는 서비스 가용성에 영향을 주지 않습니다. 현대적 인프라는 기본적으로 이러한 안정성과 자가 치유 기능을 지원해야 합니다. 기업들이 실패하기에는 너무 중요한 특수 목적의 어플라이언스에 대한 의존을 중단하는 것은 놀라운 일이 아닙니다. 내일 웹 세미나에 참석하여 이 주제에 대한 라이브 데모에서 자세한 내용을 공유해 주십시오. 웹 세미나는 주문형 보기에도 사용할 수 있습니다. https://info.avinetworks.com/webinars/resilient-load-balancing을 확인하십시오.

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

You May Also Like
Read More

ESXi Arm v1.1

2020년 10월 6일에 ARM 아키텍처용 ESXi ARM v1.0이 공개(?)되었다. 그리고 10월 22일에는 v1.1이 공개되었다. 지원 하드웨어 v1.1 기준으로…