SIOS SANless clusters High-availability Machine Learning monitoring
고 가용성 소프트웨어로 SAP 다운 타임 방지우리는 모두 자동차, 주택, 생명에 대한 보험을 구매해야합니다. 우리가 결코 사용할 필요가없는 서비스에 대해 돈을 지불하는 것을 좋아하는 사람은 없습니다. 그러나 우리 모두는 만일을 대비하여 그것을 가져야한다는 것을 알고 있습니다. 대부분의 사람들은 끔찍한 일이 생길 때까지 보험을 들거나, 가장 싼 물건을 사거나, 실제로 숙제를하고, 신뢰하는 사람에게서 산다. 이 마지막 그룹은 일반적으로 가장 좋습니다.
SIOS에 대한 고객 경험을위한 소프트웨어 엔지니어 인 저는 종종 온-프레미스 고 가용성 클러스터링 환경을 클라우드로 마이그레이션하는 회사를 돕습니다.
클라우드 마이그레이션은 대상이 아닌 프로세스입니다. 고객이 클라우드로 전환하는 과정에서 고객이 클라우드로 마이그레이션하는 데 이상적이지는 않지만 계획 프로세스가 늦어지는 경우가 종종 있습니다. 다음은 우리가 너무 자주 본 6 가지 클라우드 마이그레이션 문제입니다.
온 프레미스에서 클라우드로 데이터를 가져 오는 데 얼마나 걸립니까? 애플리케이션, 데이터 유형 및 클라우드 제공 업체에 따라 크게 달라질 수 있습니다. 간과되는 세부 사항 중 하나는 기본 노드에서 보조 노드로, 때로는 재해 복구 (DR) 사이트로 데이터를 동기화하는 데 필요한 시간입니다. 재 동기화 시간을 고려하지 않은 고객은 데이터가 복제되는 동안 엄지 손가락을 돌리고 있습니다.
클라우드 지역 내 데이터 전송은 무료입니다. 리전 간 데이터 전송에는 비용이 발생합니다. 일반적으로 기본 노드와 보조 노드가 한 지역 내 별도의 클라우드 가용성 영역에있는 아키텍처를 볼 수 있습니다. DR 사이트는 항상 다른 지역에 있기 때문에 DR 사이트를 도입하면 비용이 크게 증가 할 수 있습니다. SAP NetWeaver와 같이 데이터가 풍부한 애플리케이션의 재해 복구는 여러 지역에 복제하는 데 비용이 많이들 수 있습니다.
리전 간 복제에는 또 다른 문제인 복제 유형이 있습니다. AZ 내에서 비동기 또는 동기 복제는 고객의 RTO 및 RPO 요구 사항에 따라 결정됩니다. 인스턴스 크기에 관계없이 리전 간 교차시 데이터 복제에 약간의 지연이 발생합니다. SIOS는 해당 대기 시간의 영향을 줄이기 위해 리전 간 비동기식 복제를 권장합니다. Concurrency Labs는 EC2 리전 간 지연 시간에 대한 통찰력있는 정보를 제공했습니다.
클라우드에서 기성품 OS 이미지를 배포 할 수 있습니다. 이 편리함은 비용이 들고 구성 관리에 또 다른 요소가 도입됩니다. 클라우드에 최적화 된 SuSE Enterprise Linux 이미지에 포함 된 클라우드 초기화 서비스는 사용자 정의 가상 IP 주소를 제거 할 수 있습니다. 2 분마다 가상 IP 주소가 사라지는 것처럼 PoC를 멈추는 것은 없습니다!
클라우드 컴퓨팅의 규모는 기업이 온 프레미스 데이터 센터에서 제공 할 수있는 것보다 더 큰 보안을 제공합니다. 클라우드 워크로드는이를 모르더라도 최첨단 보안을 활용합니다. 예를 들어 기본적으로 AWS EC2 인스턴스는 인스턴스 자체에서 보내지 않거나 인스턴스 자체로 보내지 않은 트래픽을 차단합니다. 이는 클라우드에서 네트워크를 보호하는 데 유용한 기능입니다. 시스템에 NAT (Network Address Translation)가 필요한 경우 EC2 기본 보안 조치로 인해 IP 주소가 실패합니다. 콘솔에서 소스 / 대상 확인을 비활성화하면 문제가 해결됩니다. 사용자가 AWS에 익숙한 정도에 따라 몇 번의 클릭만으로 몇 번의 지원 요청이있을 수 있습니다. 성공적인 클라우드 마이그레이션을 위해서는 환경에서 시스템이 상호 작용하는 방식에 대한 이해가 중요합니다.
온 프레미스 시스템을 사용하는 고객은 리소스가 더 이상 제한 요소가 아니라는 점을 상기시켜야합니다. 클라우드에서 시스템은 쉽게 사내에서 사소한 문제가 아닌 프로덕션과 별도로 복사하고 실행할 수 있습니다. IT 리소스에 대한 주문형 액세스를 통해 HA 및 DR의 UAT는 "기본 노드 종료"이상으로 확장 할 수 있습니다. 네트워크가 파괴 될 수 있고, 커널이 패닉 될 수 있으며, 데이터베이스조차 손상 될 수 있으며,이 중 어느 것도 프로덕션에 영향을 미치지 않습니다! 이러한 시나리오를 식별하고 테스트하면 HA 및 DR 자세가 향상됩니다.
성공적인 클라우드 마이그레이션을 실행하려면 모든 이해 관계자의 의견이 필요합니다. 고 가용성 및 재해 복구는 모든 엔터프라이즈 워크로드의 핵심 측면입니다. SIOS가 이미 현재 시스템의 일부이거나 향후 클라우드 마이그레이션의 일부 일지라도 참여하십시오!
-Harrison Howell, 고객 경험을위한 소프트웨어 엔지니어
SIOS의 허가하에 재생
Linux® 용 SIOS Protection Suite 버전 9.5를 발표하게 된 것을 자랑스럽게 생각합니다. 이 제품은 고급 자동화 및 애플리케이션 인식 모니터링을 도입하여 업계에서 가장 포괄적 인 즉시 사용 가능한 SAP S / 4HANA 클러스터링 소프트웨어입니다.
SAP S / 4HANA 클러스터를 수동으로 구축해야하는 번거 로움을 알고 모든 HANA 서비스가 올바른 위치로 장애 조치되고 올바른 순서로 시작되도록합니다. 스크립팅, 테스트 및 악화 시간. 그리고 스테이크가 높습니다. 잘못되면 장애 조치 (failover)가 발생하지 않거나 다운 타임, 데이터 손실, 많은 사용자가 전화를 걸음을 의미 할 수 있습니다.
그래서 HANA (HANA System Replication)를 사용하는 2 노드 SAP S / 4HANA 데이터베이스 구성에 지능적인 애플리케이션 가용성을 추가했습니다. 클러스터를 구축하고 관리하는 번거 로움과 위험을 없애기 위해이 릴리스를 구축했습니다.
입력을 실제로 확인하는 마법사 기반의 쉬운 구성에서 시작합니다. 수동으로 스크립팅하거나 시간이 잘못되었을 때 잘못된 키 입력을 검색하지 않아도됩니다.
서버가 다른 클러스터링 소프트웨어처럼 작동하는지 확인하는 것뿐만 아니라 응용 프로그램에서 하드웨어, 서버 및 네트워크에 이르는 HANA 스택의 모든 프로세스를 모니터링합니다.
SIOS Protection Suite가 모든 문제에 대해 장애 조치를 트리거하는 다른 클러스터링 솔루션과 달리 SIOS Protection Suite가 문제를 감지하면 단순히 서비스 재시작, 서비스중인 노드에서 복구 또는 보조에 대한 장애 조치 조정 등 적절한 복구 조치를 자동으로 수행합니다. 마디.
장애 조치 오케스트레이션에 대해 말하면 SAP 특정 모범 사례가 자동으로 유지 관리됩니다. 예를 들어, 장애 조치 또는 전환시 ASCS가 기본 응용 프로그램이있는 서버 나 ERS가있는 동일한 서버에 있지 않아야합니다.
마법사 중심 구성이 쉽지 않은 경우 CLI 명령을 가져 와서 간단하게 SIOS 클러스터를 배치 할 수있는 새로운 CLI (명령 줄 인터페이스) 복제 기능도 추가했습니다. 기존 클러스터의 CLI 명령어를 내보내 복제본을 만들 수도 있습니다.
이제 Linux 용 SIOS Protection Suite를 사용하면 모든 응용 프로그램을 보호하기 위해 빠르고 쉽게 고 가용성 클러스터를 만들 수 있습니다. 여기에는 다운 타임 및 재해로 인한 SQL Server, Oracle, SAP 및 S / 4HANA가 포함됩니다.
SIOS의 허가하에 재생
EC2 모니터링 모범 사례 : SIOS AppKeeper를 사용하여 Amazon EC2에서 NGINX 웹 서버 보호NGINX는로드 밸런서, 리버스 프록시 등으로 작동 할 수있는 웹 서버입니다. NGINX와 Apache는 웹 트래픽의 50 % 이상을 처리합니다. 오늘날 많은 회사들이 Amazon Linux, Red Hat Linux 및 Ubuntu를 사용하여 Amazon EC2 환경에서 NGINX Open Source 또는 NGINX Plus 웹 서버를 실행하고 있습니다.
누구나 EC2에서 NGINX와 같은 응용 프로그램을 모니터링하고 모든 시스템 불규칙성에 신속하게 대응하는 것이 가장 좋습니다. 사용자는 애플리케이션에 대한 빠른 액세스와 지속적인 가동 시간을 기대합니다.
많은 회사에서 애플리케이션을 모니터링하기 위해 Amazon CloudWatch를 배포하고 있으며 스크립트를 개발하거나 AWS Lambda를 사용하여 일정 수준의 자동화를 만들고 있습니다. 그러나 사용자 지정 지표를 사용하여 Amazon CloudWatch를 올바르게 구성하고 Amazon Lambda를 설정하려면 많은 회사의 전문 지식을 넘어서는 상당한 기술 전문 지식이 필요합니다. 그리고 응용 프로그램이 발전함에 따라 스크립트를 유지 관리하는 데 비용과 노력이 필요합니다.
다른 선택은 New Relic, Dynatrace, Datadog 또는 LogicMonitor와 같은 APM (Application Performance Monitoring) 솔루션을 배포하는 것입니다. APM 솔루션은 훌륭합니다. 그들은 모든 시스템을 감시하고 일어난 일과 이유를 정확히 찾아내는 훌륭한 일을합니다. 개발 팀과 공유하고 해석 할 수있는 로그를 생성하여 문제를 재현하고 다시 발생하지 않도록합니다. here APM 솔루션은 정렬해야하는 많은 데이터를 제공하고 ( "소음에서 신호"분리) 장애 발생시 복구하지 않습니다. APM 도구는 NGINX 웹 서버의 가동 중지 시간을 줄이는 데있어 솔루션의 일부일뿐입니다.
그러나 일부 회사에는 EC2 환경을 자체적으로 모니터링 할 내부 직원이나 도구가 없습니다. 이것이 그들이 관리 서비스 제공자에게 작업을 아웃소싱하기로 선택한 이유입니다. 환경이 확장됨에 따라 더 많은 직원을 고용 할 필요가 없거나 새로운 기술에 대해 팀을 교육 할 필요가없는 등 MSP와 함께 작업하여 환경을 관리하면 실질적인 이점이 있습니다. 그리고 MSP는 많은 고객에게 투자를 분산시킬 수있어 효율성을 누리고 있습니다. 그러나 단점이 있습니다. 경우에 따라 고정 비용이 높은 계약에 고정 될 수 있으며 문제가 발생하여 문제를 해결하기 위해 비용을 상승시켜야하는 경우 비용이 상승 할 수 있습니다. 또한 환경을 모니터링하는 팀과 응용 프로그램을 구축 및 배포하는 담당자 간의 연속성을 잃게됩니다.
APM 솔루션에 투자하든 MSP에 아웃소싱하든 관계없이 NGINX 웹 서버를 중단 시간과 시점에 얼마나 빨리 복구 할 수 있는지 생각해야합니다. 우리는 또 다른 대안을 제안하고자합니다 : SOIS AppKeeper를 이용한 자동 치료.
많은 고객이 SIOS AppKeeper를 사용하여 NGINX 웹 서버를 보호하기로 선택했습니다. 표준 APM (애플리케이션 성능 모니터링) 솔루션 또는 타사 모니터링 솔루션을 선택할 수 있었지만 대신 장애 발생시 서비스 또는 전체 EC2 인스턴스를 자동으로 복구하기 위해 AppKeeper를 사용하기로 결정했습니다. AppKeeper가 NGINX와 어떻게 작동하는지 보여주는 짧은 비디오를 소개하고 그 이유를 몇 가지 살펴 보겠습니다.
SIOS AppKeeper는 NGINX 웹 서버 및 "nginx", "캐시 관리자"및 "작업자"서비스와 같이 Amazon EC2에서 실행중인 모든 애플리케이션을 쉽게 설치 및 구성하고 모니터링하는 SaaS 서비스입니다. 이상이 감지되면 AppKeeper가 자동으로 서비스를 다시 시작하고, 작동하지 않으면 전체 인스턴스를 재부팅합니다. 더 이상 고통스러운 로그를 읽지 않아도 실패의 원인을 찾아 내거나 개발자에게 서비스를 다시 시작하거나 비싼 아웃소싱 비용을 에스컬레이션 할 수 있습니다. AppKeeper는 NGINX 웹 서버가 EC2 모니터링 모범 사례를 따르고 있으며 제대로 실행되고 있거나 문제가 발생하면 신속하게 다시 시작될 것임을 확신 할 수 있도록 "set-it-and-forget-it"기능을 제공합니다.
오늘날 수백 개의 회사가 AppKeeper를 사용하여 클라우드 환경을 계속 운영하고 있습니다. AppKeeper가 NGINX 웹 서버를 보호하는 방법에 대한 데모를 보려면이 빠른 비디오를 확인하십시오.
SIOS AppKeeper를 직접 체험하고 싶다면 14 일 무료 평가판을 제공합니다. 가입하려면 여기를 클릭하십시오.
AWS가 클라우드 시장에서 지배적 인 점유율을 차지하면서 많은 회사들이 Amazon AWS를 사용하여 온 프레미스 시스템을 클라우드로 마이그레이션하고 있습니다. 그렇다면 AWS 환경에서 실행되는 시스템을 어떻게 관리해야합니까?
이 블로그 게시물에서는 AWS에서 제공하는 모니터링 서비스 인 Amazon CloudWatch의 기능과이를 구현하는 문제 및 해결 방법을 소개합니다.
안정적인 클라우드 환경을 유지하려면 이상 ( "시스템 손상")을 신속하게 감지하여 적시에 대응하는 것이 중요합니다. 클라우드로 이동하는 모든 조직에서 모니터링은 중요하고 필요한 작업이됩니다. 온 프레미스 응용 프로그램 및 인프라를 관리하는 경우와 다르지 않습니다. 그렇다면 AWS 환경에서 어떻게 모니터링해야합니까? 한 가지 선택은 CPU, 메모리 및 디스크 사용량을 모니터링하고 미리 결정된 임계 값을 초과 할 때 알려주는 Amazon CloudWatch를 사용하는 것입니다. 또한 응용 프로그램 로그와 같은 다양한 항목을 모니터링하도록 고유 한 메트릭을 설정할 수 있습니다.
Amazon CloudWatch의 가장 큰 장점은 AWS 자체에서 제공하는 서비스라는 것입니다. Amazon EC2 및 기타 AWS 서비스와의 친화력이 높기 때문에 빈번한 기능 확장 및 사양 변경에 신속하게 대응할 수 있으며, AWS Auto Scaling을 쉽게 지원할 수있어로드에 따라 리소스를 자동으로 늘리거나 줄입니다. Amazon CloudWatch는 각 환경의 고유 한 환경에 맞는 정밀한 모니터링을 제공합니다.
Amazon CloudWatch는 숙련 된 클라우드 엔지니어 및 DevOps 팀이있는 조직에 이상적이지만 일반 사용자가 알아야 할 사항이 있습니다.
Amazon CloudWatch는 조직의 AWS 환경을 모니터링하는 데 효과적이지만 구성 및 배포에는 특정 수준의 기술과 지식이 필요합니다. 특히 자체 메트릭을 설정하거나, 경고를 설정하거나, Auto Scaling을 고려할 때 복잡성이 증가합니다. 예를 들어 모니터링을 설정하는 것은 쉽지만 리소스 상황에 따라 이메일, 재부팅, AutoScaling 등을 설정하는 경우 어려울 수 있습니다.
"오류 발생시 서버 다시 시작"과 같은 지침으로 복구 프로세스를 자동화하려면 먼저 수행 할 조건 및 조치에 대한 자세한 설명을 제공하는 AWS Lambda 스크립트를 사용하여 복구 시나리오를 생성해야합니다. 팀이 AWS Lambda에 얼마나 익숙합니까?
Amazon CloudWatch의 주요 장점은 환경을 면밀히 모니터링 할 수 있다는 점이지만,이를 위해서는 모니터링 할 항목과시기, 임계 값 등을 각 시스템에 대해 사전에 올바르게 설계해야합니다. 이러한 설계 작업에는 많은 시간이 걸릴 수 있습니다. 물론 이러한 방식으로 미션 크리티컬 한 시스템을 면밀히 모니터링해야하지만이 수준의 세부 사항과 정교함이 모든 시스템에 적합한 것은 아닙니다. 내부 웹 사이트 또는 WordPress 서버와 같은 일부의 경우 운영 및 인건비를 최소화해야합니다. 이 경우 더 쉽게 운영하고 관리 할 수있는 도구를 고려해 보시기 바랍니다.
미션 크리티컬 애플리케이션의 경우 SIOS Technology의 SIOS AppKeeper를 권장합니다. AppKeeper는 EC2 인스턴스에서 실행되는 애플리케이션의 서비스 (프로세스)를 쉽게 설치 및 구성하고 모니터링합니다. AppKeeper는 오류가 감지되면 서비스를 자동으로 다시 시작하고 필요한 경우 인스턴스를 재부팅합니다. 클라우드로 처음으로 이동하는 사용자조차도 정교한 스크립팅 기술이 없어도 AppKeeper가 EC2 인스턴스를 모니터링하고 자동으로 복구하도록 AppKeeper를 설정할 수 있습니다.
AppKeeper를 사용하면 모니터링 할 개별 서비스를 선택할 필요가 없습니다. 모니터링 할 EC2 인스턴스와 자동으로 수행 할 작업을 선택하면됩니다. 모니터링 할 서비스와 방법에 대해 더 구체적으로 알 수 있지만 AppKeeper는 기본적으로 쉽게 구성 할 수 있도록 설계되었습니다. 오류가 감지되거나 자동으로 복구되면 오류의 원인을 나중에 조사 할 수 있도록 오류 로그가 기록 및 저장됩니다.
Amazon CloudWatch를 사용하여 AWS 환경의 모든 것을 면밀히 모니터링하는 대신 SLA 및 복구 요구 사항을 기반으로 환경 인벤토리를 생성하고 SIOS AppKeeper를 사용하여 운영 오버 헤드를 줄이려는 시스템 및 애플리케이션을 모니터링하는 것이 좋습니다.
동일한 기능을 수행하도록 CloudWatch와 AppKeeper를 설정하는 방법을 비교하여 자세히 설명 할 향후 블로그 게시물을 계속 지켜봐 주시기 바랍니다.