SIOS APAC Portal

1월 16, 2021	AWS에서 Zabbix를 계속 사용해야합니까? AWS에서 Zabbix를 계속 사용해야합니까? Amazon EC2 모니터링 Zabbix는 통합 OSS 모니터링 도구로서 시장 점유율이 높습니다.온 프레미스 환경에서 널리 사용되었지만 AWS 환경에서 사용되는 Zabbix의 많은 예가 있습니다.AWS에도 Amazon CloudWatch와 같은 모니터링 서비스가 있지만 Zabbix를 사용해야하는 이유는 무엇입니까?이 섹션에서는 EC2 인스턴스 및 기타 인스턴스 모니터링의 이점과 구성 프로세스에 대해 설명합니다. Amazon CloudWatch 대신 Zabbix를 사용하는 이유는 무엇입니까? AWS 환경에서 모든 인프라는 AWS에서 운영하지만 Amazon EC2 인스턴스 자체와 Amazon EC2에 구축 된 애플리케이션의 운영을 책임 져야합니다. 즉, 응용 프로그램이 제대로 작동하는지 모니터링하고 문제가 발생하면 조치를 취해야합니다.Zabbix는 이러한 종류의 모니터링 도구에 적합한 후보입니다. Zabbix는 온 프레미스뿐만 아니라 모니터링 할 수 있다는 장점이 있습니다. 또한 통합 된 방식의 클라우드 및 가상 환경. 표준 Amazon CloudWatch는 AWS 리소스 (CPU, 메모리 등) 모니터링으로 제한되지만, Zabbix를 사용하면 애플리케이션 상태까지 자세히 모니터링 할 수 있습니다. 다음은 Zabbix의 다른 장점 목록입니다. 여러 AWS 계정이있는 환경의 통합 모니터링 Amazon CloudWatch는 AWS 계정별로 모니터링을 수행합니다.Zabbix는 여러 계정으로 구성된 비즈니스 시스템을 모니터링 할 수있는 여러 AWS 계정의 환경을 모니터링 할 수 있습니다.또한 임계 값을 기반으로하는 단순한 경고뿐만 아니라 여러 임계 값과 조건을 조합하여 이상을 감지 할 수 있습니다. 실제 작동 조건에 맞게 세부 알림으로 구성 할 수 있습니다. Amazon CloudWatch는 이상이 발생하는 경우 메시지로 알릴 수 있습니다.예를 들어 시스템이 유지 관리를 위해 다운 된 경우 메시지로 알림을받을 필요가 없습니다.여기에서 Zabbix를 사용하면 원하지 않는 메시지를 억제 할 수있는 방식으로 이러한 경우를 구성 할 수 있습니다.이렇게하면 해결해야하는 문제가 실제로 잘못되었을 때만 알림을받을 수 있습니다. 메트릭에 대한 보존 기간 없음 (모니터링 로그) Amazon CloudWatch를 사용하면 지표를 최대 15 개월 동안 저장할 수 있습니다.또한 15 개월 동안 시간 단위로만 메트릭을 저장할 수 있으며 모니터링 간격이 60 초 미만으로 설정된 경우 최대 3 시간 동안 만 저장할 수 있습니다.Zabbix를 사용하면 정보의 세분성을 변경하지 않고도 메트릭을 장기적으로 저장할 수 있습니다. Zabbix로 AWS 환경을 모니터링하는 방법 AWS에서 Zabbix를 사용하려면 Amazon EC2 및 DB 인스턴스를 생성하고 여기에 Zabbix를 설치해야합니다.설치 후 Zabbix를 구성하는 프로세스는 기본적으로 온 프레미스와 동일하지만 다음을 설정해야합니다. 사용자 계정 (Zabbix의 Admin 사용자 외에 프로덕션 용 사용자를 생성해야 함) Zabbix 호스트 에이전트 (데이터 수집 위치 결정) 항목 (수집 할 데이터 설정) 트리거 (비정상적인 데이터 상태 정의) 조치 (오류 발생시 취할 조치 정의) 또한 Zabbix에 필요한 권한을 사용하여 AWS IAM에서 사용자를 생성하는 등의 AWS 관련 설정을 구성 할 수 있습니다. 이렇게하면 Zabbix가 애플리케이션 및 AWS 환경의 다른 측면을 모니터링 할 수 있습니다. 모니터링 요구 사항에 적합한 도구 사용 모든 기업 시스템이 독립적으로 작동하는 것은 아니지만 많은 시스템이 함께 연결되어 데이터를 교환하고 전체적인 일관성을 보장합니다.이러한 환경에서 Zabbix는 여러 서버 및 시스템에서 이상 징후를 모니터링하고 감지하는 데 유용한 도구입니다.예를 들어, DB 기반 웹 애플리케이션이 웹 애플리케이션 서버에 이상이있는 경우 데이터를 비활성화 할 수 있습니다. 반면 Zabbix에는 많은 구성 옵션이 있으므로 모니터링 할 대상과 방법, 비정상적인 조건을 결정해야합니다. 반면 Zabbix에는 많은 설정이 있으므로 모니터링 할 대상과 수행 할 작업 및 수행 할 작업을 정확하게 설계해야합니다. 물론 중요한 시스템의 경우 이러한 설계가 필수적이지만 "프로세스가 중지되면 다시 시작하십시오"와 같은 비교적 간단한 시스템의 경우 Zabbix 모니터링과 일치하지 않습니다.SIOS AppKeeper는 EC2 인스턴스에서 실행되는 애플리케이션의 서비스 (프로세스)를 모니터링하고 문제가 감지되면 애플리케이션을 다시 시작하므로 이러한 경우에 적합한 솔루션입니다. 이를 통해 간단한 모니터링 및 작동이 가능합니다. 물론 모든 시스템에서 Zabbix를 사용하는 것이“필수”는 아닙니다.각 모니터링 유형에 적합한 도구를 사용하면 시스템을보다 효율적으로 운영 할 수 있습니다. EC2 모니터링 및 복구 작업에 SIOS AppKeeper를 추가합니다. SIOS에서 재현
1월 8, 2021	고 가용성이 필요할 때 클라우드를 선택하는 방법 고 가용성이 필요할 때 클라우드를 선택하는 방법 클라우드 시장 이해 많은 분석 회사가 클라우드에서 애플리케이션, 데이터베이스 및 솔루션의 배포 수가 계속 증가 할 것으로 예측하고 있습니다. Gartner에 따르면 기업들은 "빠른 속도로 클라우드로 전환"하^[1]고 있습니다. 실제로 Gartner와 다른 분석가들은 클라우드의 혁신 속도에 따라 클라우드 마이그레이션 및 배포 속도가 계속 가속화 될 것으로 예상합니다. MarkoInsights의 Kurt Marko가 작성한 TechTarget 기사에서 Marko는 "클라우드에서 수행되는 혁신 속도는 관리 형 공용 클라우드의 탄력적이고 확장 가능한 주문형 특성으로 인해 온 프레미스에서 복제 할 수 없을 가능성이 높습니다. 서비스." 비즈니스에 필수적이지 않은 DevOps 애플리케이션 및 데이터베이스에만 클라우드를 사용하던 기업이 이제는 고 가용성 보호가 필요한 미션 크리티컬 애플리케이션, ERP 및 데이터베이스를 클라우드로 이동하고 있습니다. 클라우드로의 이전을 고려하고있는 것 같다면 고 가용성이 필요할 때 이해해야 할 몇 가지 핵심 사항이 있습니다. 클라우드 고 가용성 옵션을 숙지하십시오. 클라우드 또는 하이브리드 클라우드 배포를위한 적절한 가용성 솔루션을 계획하려면 가용성 (99.9 % 가동 시간) 및 고 가용성 (99.99 % 가동 시간)과 관련하여 문제점이 무엇인지 고려하십시오. 또한 클라우드로 마이그레이션하려는 계획을 염두에두고 고 가용성에 사용할 수있는 옵션을 이해해야합니다. 주목할만한 분석가와 전문가는 워크로드 마이그레이션의 어려움을 완화하고 줄일뿐만 아니라 클라우드 아키텍처의 수명 기간 동안 가용성에 대한 균형적이고 포괄적 인 접근 방식을 제공 할 솔루션을 찾을 것을 제안합니다. 언젠가 클라우드에서 온-프레미스 환경으로 다시 돌아갈 수있는 워크로드 부분에 대해 보호 및 고 가용성을 제공 할 수있는 솔루션을 고려하는 것도 현명합니다. 클라우드에서 가용성 옵션을 비교할 때 고려해야 할 10 가지 사항은 다음과 같습니다. 1. 배포 방법. 이미지, CLI, UI 또는 클라우드 형성 템플릿 또는 패키지 스크립트와 같은 기타 반복 가능한 솔루션을 사용하여 고려중인 가용성 솔루션을 배포 할 수 있습니까? 2. 시스템 요구 사항.특히 운영 체제 (OS), 디스크, CPU 및 메모리 요구 사항을 고려하십시오. 삼. 배포 환경.가용성 옵션이 온-프레미스 만, 하나 이상의 퍼블릭 클라우드를 지원합니까, 아니면 혼합 및 / 또는 하이브리드 클라우드 배포를 지원할 수 있습니까? SaaS 제품도 사용할 수 있습니까? 4. 애플리케이션 보호의 폭과 깊이. "폭"이란 어떤 유형의 애플리케이션, 데이터베이스, 프런트 엔드, 네트워킹 및 인프라 구성 요소를 보호 할 수 있는지를 의미합니까?새로운 애플리케이션과 변형을 추가하기위한 유연한 프레임 워크가 있습니까? “깊이”의미 – 솔루션이 애플리케이션을 인식하고 있으며 애플리케이션 장애 조치 / 장애 복구 프로세스 전반에 걸쳐 애플리케이션 별 모범 사례를 유지할 수 있습니까? 5. 성능 요건. 우리는 종종 RTO 및 RPO를 생각하지만 솔루션의 다른 성능 요구 사항은 어떻습니까? 가용성 솔루션으로 인해 장애 조치시 성능 문제가 발생합니까? 6. 탄력성 요구 사항.가용성 솔루션이 지원할 수있는 클러스터 크기는 얼마입니까?, 얼마나 많은 결함과 실패를 감지하고 복구 할 수 있습니까? 메타 데이터를 동기화 상태로 유지하면서 복제는 어떻게 처리됩니까? 7. 지원 가능성 및 유지 관리.가용성 공급 업체는 다양한 가용성 요구 사항 및 구성에 대한 경험이 있습니까? 수명이 길고 솔루션을 넘어 설 수있는 문제를 해결하도록 설계된 지원 시스템이 있습니까? 시스템 관리 및 유지 관리 (패치, 업그레이드 및 일반 유지 관리) 중에 중단 및 계획된 다운 타임을 최소화하는 데 도움이 될 수 있습니까? 8. 총 소유 비용.총 소유 비용을 계산하는 데 전념하는 전체 산업 및 서비스가 있으므로 여기서는 다루지 않겠습니다. 계산은 조직, 클라우드 제공 업체, 애플리케이션 및 IT 팀에 고유 한 것입니다. 가용성 솔루션 공급 업체가 활용도, 라이선스 및 기타 비용을 절약하기위한 전략을 식별하는 데 도움을 줄 수 있는지 고려해야합니다. 솔루션이 수동 작업을 자동화하고 IT 노동 시간을 줄입니까? 9. 라이선스 및 가격 모델.소프트웨어 비용을 어떻게 소비합니까? 구독료, 구독 모델, 종량제 서비스, BYOL (Bring Your Own License) 또는 유연한 옵션 조합이 있습니까? 제품 라이센스를 어떻게 활성화합니까?주소, 호스트 이름, MAC 주소와 같은 가상 머신 배포 세부 정보를 기반으로하는 라이선스 서버, 라이선스 서비스 또는 암호화 된 키가 있습니까? 10. IT 직원에게 미치는 영향.솔루션에 대한 교육이 얼마나 필요합니까? 애플리케이션 장애 또는 재해 발생시 얼마나 많은 수동 개입이 필요합니까? 유지 관리해야하는 특수 스크립팅이 필요합니까? 지속적인 유지 관리는 누가 담당합니까? 이점과 장단점을 평가 모든 중요한 결정과 마찬가지로 트레이드 오프를 이해하고 필요에 맞는 최상의 균형을 선택해야합니다. 예를 들어, 최근에 친구에게 좋은 워킹화를 추천 해달라고 요청했습니다. 나는 그가 얼마나 가볍고, 직물이 얼마나 튼튼하고 내구성이 있는지, 그리고 얼마나 스타일리시했는지에 주목하면서 그가 열광했던 한 벌을 샀다.나는 그들에게 처음으로 긴 걷기 운동을하러 갔고, 그 직후에 첫 번째“원런”신발을 기증했습니다. 전문가의 의견을 구하기 위해 'Fleet Feet'에 갔을 때 나는 더 무거운 신발, 더 통기성있는 천 (또한 내구성이 떨어짐), 그리고 타의 추종을 불허하는 수준의 끔찍함을 갖게되었습니다. 나는 내 필요와 예산에 맞는 외모와 기능 사이에서 균형을 잡았습니다. 운동화와 마찬가지로 모든 회사, 모든 애플리케이션, 모든 데이터베이스, 가능한 모든 서버 및 아키텍처에 적합한 은색 총알 솔루션은 없습니다. 공식적으로 검색을 중단 할 수 있습니다. 대신 회사의 요구 사항에 적합한 것이 무엇인지 결정하기 위해 장단점을 평가하는 활동에 정착하십시오. 장단점에 대해 생각하십시오. 예를 들어 완전한 Microsoft 매장이 될 것이 확실하다면 GCP 및 AWS 지원의 중요성은 평가 프로세스에서 약간 낮아야합니다. IT 인프라 역학을 고려하십시오. 온 프레미스와 클라우드 모두에서 전체 IT 인프라의 가용성에 대해 전체적으로 생각하십시오. 그렇게하는 이유는 다른 비유로 가장 잘 설명됩니다. 2018 년에 저는 사우스 캐롤라이나 주 컬럼비아에서 노숙자와 배고픈 사람들을위한 봉사 프로그램의 코디네이터였습니다. 우리 그룹은 일주일에 한 번 만나서 100 명이 넘는 남성, 여성, 어린이들에게 식사와 희망의 메시지를 제공했습니다. 확장을 고려할 때 요일, 시간 또는 서비스 추가를 고려할 때 단순한 일정 요구 사항 이상을 생각해야했습니다. 우리에게 의존하는 고객에게 중요한 서비스를 제공하고 있다는 사실을 알고 있었기 때문에 비용, 팀원의 연령, 외부 의무와 같이 장기적으로 이러한 서비스를 지속적으로 제공하는 능력에 영향을 미치는 모든 요소를 고려해야했습니다. , 상위 조직 내에서 목표, 위험 요소 및 기타 역학을 달성하기위한 대체 방법. 솔루션을 선택할 때 시장을 이해하고 옵션에 익숙해지고 장단점을 평가 한 후 마지막 단계는 전체 환경의 다양한 기타 역학을 고려하는 것입니다. 솔루션이 비즈니스 전체의 요구 사항을 충족합니까? 중요한 데이터가 손실되지 않도록 보호됩니까? 최종 사용자 생산성이 다운 타임으로부터 보호됩니까? 클라우드로 이동하려면 어떤 교육이 필요하며 선택한 솔루션을 관리하거나 유지하는 능력에 어떤 영향을 미칠까요? 클라우드 여정에서 어떤 IT 역할이 추가, 제거 또는 변경됩니까?애플리케이션 가용성에 대한 책임이 LOB (기간 업무) 소유자에게로 이전됩니까? 그리고 책임의 변화 또는 팀이 어떻게 전체적인 성공 가능성을 개선하거나 감소시킬 것입니다. 팀에서 더 작은 워크로드를 먼저 마이그레이션하여 단계별 접근 방식을 취해야하는지 고려하십시오. 고객 경험 담당 부사장으로서 저는 광범위한 클라우드 마이그레이션 계획을 보았습니다. 일부는 간단하고 일부는 매우 파괴적입니다. 어떤 경우에는 경영진이 IT 부서 전체를 제거 할 수있는 기회로 인식했기 때문에 고객이 클라우드로 이전하는 것이 매우 논쟁의 여지가있었습니다. 나는 당신이 정치를한다고 제안하는 것은 아니지만,이 복잡한 프로젝트에서 작용하는 모든 요소를 알고 있어야합니다. 클라우드로 마이그레이션하면 비용, 시간 및 리소스를 절약하는 동시에 가용성과 복원력을 향상시킬 수 있습니다. 어떤 클라우드를 선택하든 이러한 팁을 고려하고 원하는 구성에서 필요한 보호를 제공 할 수있는 유연성을 제공하는 해당 가용성 솔루션을 선택해야합니다. SIOS를 사용한 클라우드 고 가용성 옵션에 대해 자세히 알아보세요. – Cassius Rhue, SIOS 고객 경험 담당 부사장 SIOS의 허가를 받아 복제
12월 30, 2020	더 나은 결과로 클라우드에서 가용성을 복제하는 방법 더 나은 결과로 클라우드에서 가용성을 복제하는 방법 영화 팁 – 다중성 Multiplicity는 1996 년 미국 공상 과학 코미디 영화로 Michael Keaton이 그의 가족과 까다로운 직업을 위해 시간을 내기 위해 고군분투하는 바쁜 건설 노동자 Doug Kinney 역으로 주연을 맡았습니다. 과학자가 그를 복제하겠다고 제안했을 때 Doug는 자신의 일정과 약속을 더 쉽게 충족시키는 데 동의합니다. 그러나 그의 사본은 자신의 사본을 만들기 시작합니다. 마지막 사본이 만들어 질 때까지 요점은 분명합니다. 복제만으로는 충분하지 않을 수도 있고 최소한 몇 가지 강력한 경고, 문제 및 부작용이있을 수 있습니다. 유명한 오리지널 스타 트렉 에피소드“Trouble with Tribbles”는 비슷한 점을 보여줍니다. 큰 화면 (또는 작은 화면)에서의 복제와 마찬가지로 클라우드에서의 복제는 훌륭한 도구이지만 문제가없는 것은 아닙니다. 클라우드에서 가용성을 복제 할 때 더 나은 결과를 얻는 방법에 대한 팁 1. 운영 체제 복제 이것은 당연한 것처럼 들리지만 실제 기업 환경에서 두 번 이상 발생하는 것을 보았습니다. 작동하지 않는 시스템을 복제하면 복제가 작동하지 않고 복원 할 때 문제가됩니다. 만든 클론이 운영 및 기능 시스템에서 생성되었는지 확인합니다. 2. 데이터를 디스크에 동기화하고 복원시 다시 동기화 파일 시스템 무결성이 중요합니다. 애플리케이션 및 / 또는 VM이 일관된 상태인지 확인하지 않는 경우 대부분의 공급 업체는 생성 된 결과 이미지를 보장하지 않습니다. 스냅 샷은 스냅 샷 명령이 실행될 때 볼륨에 기록 된 데이터 만 캡처하므로 모든 애플리케이션 또는 운영 체제에서 캐시 한 모든 데이터를 제외 할 수 있습니다. 데이터가 파일 시스템에 올바르게 동기화되었는지 확인하는 것은 중요한 단계이며 클러스터 환경에서 절대적으로 중요합니다. 이미지에서 복원 할 때 파일 시스템 무결성도 염두에 두어야합니다. 데이터 복제를 사용 중이고 이미지를 클러스터의 소스 또는 대상으로 복원하는 경우 두 노드가 동기화되어 있는지 확인하는 것이 가장 중요합니다. 그렇게하지 않으면 장애 조치 또는 전환시 파일 시스템 오류가 발생하거나 데이터가 손실 될 수 있습니다. 클라우드에서 가용성을 복제하여 원하는 결과를 얻으십시오. 3. 인스턴스 중지 많은 환경에서는 이미지를 생성하기 위해 인스턴스를 중지 할 필요가 없으며 AWS와 같은 일부 환경에서는 복사하기 전에 노드 전원을 끄는 단계를 수행합니다.그러나 많은 도구와 사이트에서는 손상, 무결성 손실 또는 설치된 응용 프로그램을 시작, 중지 또는 실행하는 데 문제가있는 이미지를 생성하지 않도록 응용 프로그램을 중지하고 파일 시스템 액세스를 올바르게 동기화 할 것을 권장합니다. 4. 클라우드의 모든 항목 (노드, 디스크, NIC, 모든 항목)에 라벨 지정 클론 생성은 무료 작업이지만 결과 디스크와 구성 요소는 일반적으로 그렇지 않습니다.예를 들어 AWS는 "이미지를 등록 취소하고 스냅 샷을 삭제할 때까지 스냅 샷에 대한 요금이 부과됩니다"라고 말합니다. 항목에 라벨이 지정되지 않은 경우 사용중인 항목과 사용하지 않는 항목 및 만든 이유를 알면 문제가 될 수 있습니다. 또한 기존 팀원들의 덧없는 기억이나 집중력 저하의 영향을받습니다.모든 것에 라벨을 붙입니다. 5. 클론과 스냅 샷을 자주 정리 (비용 절감 및 골치 아픈 일 절감) 오래된 스냅 샷과 클론을 정리하면 비용을 절감 할 수있을뿐만 아니라 골칫거리를 줄이는데도 좋습니다.오래된 스냅 샷은 최신 복사본에서 해결되거나 해결 된 취약성을 다시 도입 할 위험이 있습니다.SIOS Technology Corp.의 고객 경험 부사장으로서 스냅 샷에서 복원 한 고객과 함께 작업했을 때 그 결과를 직접 보았습니다. 응용 프로그램을 다시 시작하면서 몇 가지 문제가 발생했습니다. 문제 해결 후 복제본이 이전 버전의 보안 소프트웨어를 실행하고 있음을 확인했습니다. 사용자 프로필에 저장된 캐시 된 자격 증명 및 메타 데이터는 더 이상 외부 탑재 데이터 드라이브에 저장된 실제 애플리케이션 데이터와 동기화되지 않았습니다. 6. 클라우드에서 클론 복제 제한 또는 제한 마지막으로 클라우드에서 수행하는 모든 작업을 복제 할 필요는 없습니다. 복제 할 워크로드 유형을 제한하고 환경에서 복제를 생성 할 수있는 역할의 수를 제한하십시오. 영화에서 Doug의 클론이 자신의 복제 시리즈를 촉발했을 때 이미 압도 된 Doug (Michael Keaton)는 아내에게서 만든 엉망진창을 숨기려고 노력하면서 자신의 많은 클론을 관리하기 위해 추가 에너지를 투입해야합니다. 클라우드에서 더 나은 결과로 클론 가용성을 달성하는 것은 어렵지 않습니다. 작업을 더 쉽게 만들고 환경을 더 안전하게 만드는 도구에서 더 많은 작업을 수행하고 위험을 추가하지 않도록 신중하게 복제하십시오. – Cassius Rhue, 고객 경험 담당 부사장 SIOS에서 재현
12월 26, 2020	신제품 릴리스 : Linux 9.5.1 용 SIOS Protection Suite 신제품 릴리스 : Linux 9.5.1 용 SIOS Protection Suite SIOS는 미션 크리티컬 애플리케이션의 고 가용성에 대한 고객의 진화하는 요구를 충족하기 위해 지속적으로 제품을 업데이트하고 있습니다. Linux 용 SIOS Protection Suite 버전 9.5.1의 일반 공급을 발표하게되어 기쁩니다.이 릴리스 기능은 더 광범위한 플랫폼에 대한 지원을 추가하고 명령 줄 인터페이스 기능을 향상시킵니다. 주요 업데이트는 다음과 같습니다. 다음 운영 체제 및 플랫폼 지원 : VMware Vsphere 7, Red Hat Enterprise Linux (RHEL) 8.2, Oracle Linux 8.2, CentOS 8.2, SUSE Linux Enterprise (SLES) 12 SP5, RHEL 7.8, CentOS 7.8, Oracle Linux 7.8, SLES 15 SP2 향상된 설정 스크립트가 포함 된 CLI 자동 설치 – 더 빠르고 간편한 구현 ARK 및 복제에 대한 확장 된 CLI 지원 – 여러 클러스터를 간단하고 일관되게 배포 할 수 있습니다. SIOS의 허가를 받아 복제
12월 22, 2020	클라우드 마이그레이션이 중단 된 6 가지 이유 클라우드 마이그레이션이 중단 된 6 가지 이유 점점 더 많은 고객이 클라우드의 유연성, 확장 성 및 성능을 활용하고자합니다. 변화하는 애플리케이션, 솔루션, 고객 및 파트너의 수가 증가함에 따라 마이그레이션이 중단되지 않도록하십시오. 클라우드 마이그레이션이 중단되는 다음 6 가지 이유 방지 1. 불완전한 클라우드 마이그레이션 프로젝트 계획 프로젝트 계획은 프로젝트 성공의 핵심 기여자로 널리 알려져 있습니다. 계획은 프로젝트 단계에서 이해 관계자, 다양한 구현 팀 및 파트너를 안내하는 데 필수적인 역할을합니다. 계획은 원하는 목표를 식별하고, 리소스와 팀을 이러한 목표에 맞추고, 위험을 줄이고, 기한을 놓치는 것을 방지하고, 궁극적으로 클라우드에서 고 가용성 솔루션을 제공하는 데 도움이됩니다.불완전한 계획과 불완전한 계획은 종종 프로젝트 중단의 큰 원인입니다.9 시간에 주요 종속성이 식별됩니다. 예기치 않은 서버 재부팅 중에 애플리케이션 모니터링 및 HA 홀이 식별됩니다 (아래 참조). 클라우드 마이그레이션에 계획이 있는지 확인하고 계획을 실행하십시오. 2. 온 프레미스 오버 엔지니어링 “이것이 우리가 온 프레미스 노드에서 수행 한 방법입니다.”라는 문구가 최근 고객 대화를 시작했습니다. 고객은 클라우드로의 마이그레이션 시도가 중단되었을 때 SIOS 전문 서비스의 프로젝트 관리자 인 Edmond Melkomian과 협력했습니다.발견 세션 중에 Edmond는 온 프레미스 대 클라우드 아키텍처와 관련된 과잉 엔지니어링 된 항목을 발견 할 수있었습니다. 일부 프로젝트의 경우 온 프레미스에서 수행 한 작업을 재현하는 것은 부풀음, 복잡성 및 지연에 대한 이력서가 될 수 있습니다. 아키텍처 및 마이그레이션 계획을 분석하고 특히 네트워킹 및 스토리지를 사용하여 과도하게 엔지니어링 된 구성 요소 및 설계를 무자비하게 제거하십시오. 3. 언더 프로비저닝 비용을 제어하고 무분별한 확장을 방지하는 것은 클라우드 마이그레이션의 중요하고 중요한 측면입니다.그러나 일부 고객은 디스크 및 대역폭에 대한 시간당 요금과 관련 비용에 대해 걱정하는 것이 부족한 프로비저닝의 함정에 빠집니다.이 트랩에서 리소스는 잘못된 속도 특성을 가진 디스크, 잘못된 CPU 또는 메모리 풋 프린트가있는 컴퓨팅 리소스, 잘못된 노드 수가있는 클러스터 등 부적절한 크기입니다.이와 같이 프로비저닝이 부족한 경우 UAT (User Acceptance Test)가 시작되고 예상 / 예상 워크로드로 인해 규모가 작은 리소스에 대한 로그 잼이 발생하면 문제가 발생합니다.또는 대상 노드의 비용 최적화가 장애 조치 시나리오에서 리소스를 제대로 처리 할 수 없습니다. 클라우드에서 가상 머신의 크기를 조정하는 것은 간단한 프로세스이지만 이러한 크기 조정 문제는 종종 설계자와 최고 재무 책임자가 리소스 재 프로비저닝의 영향을 이해하려고하는 동안 지연을 유발합니다. 4. 내부 IT 프로세스 모든 대기업에는 일련의 내부 프로세스가 있으며 팀과 회사도 예외는 아닙니다.IT 프로세스는 일반적으로 클라우드 마이그레이션 전략의 성공에 큰 영향을 미칠 수있는 프로세스 중 핵심입니다. 과거에는 많은 기업들이 입찰, 사이징 가이드, 주문 승인, 서버 준비 및 구성, 최종 배포를 포함한 긴 요청 및 인수 프로세스를 가지고있었습니다.클라우드 프로세스는 무엇보다도 컴퓨팅, 스토리지 및 네트워크 리소스를 획득하고 배포하는 방식을 획기적으로 변경했습니다.그러나 프로세스가 클라우드의 속도를 따라 가지 못한 경우 계획이 변경 될 때 마이그레이션이 중단 될 수 있습니다. 5. 불량한 고 가용성 계획 클라우드 마이그레이션이 중단 될 수있는 또 다른 이유는 고 가용성 계획과 관련이 있습니다. 고 가용성에는 도구 번들 또는 엔터프라이즈 라이선스 이상의 것이 필요합니다.HA에는 신중하고 철저하며 사려 깊은 시스템 설계가 필요합니다.HA 솔루션을 배포 할 때 계획은 용량, 중복성 및 복구 및 수정 요구 사항을 고려해야합니다. 계획을 통해 요구 사항을 적절하게 식별하고, 솔루션을 제안하고, 위험을 고려하고, 배포 및 유효성 검사에 대한 종속성을 관리합니다. 계획이 없으면 프로젝트 및 배포는 위험, 단일 장애 지점 문제, 적합하지 않음, 누락 된 계층 및 애플리케이션 보호 또는 복구 전략 수준에 취약합니다.종종 HA 계획이 부족한 경우 요구 사항이 분류되는 동안 프로젝트가 중단됩니다. 6. 불완전하거나 유효하지 않은 테스트 최종 고객을 클라우드로 마이그레이션하는 파트너 인 Ron은 다가오는 3 일 주말 동안 가동을 계획했습니다. 'go / no-go'의 마지막 결정 지점은 스테이징 서버에 대한 사용자 승인 테스트의 배치였습니다.첫 번째 테스트가 실패했습니다.다른 마이그레이션 문제로 인한 손실 된 시간을 보충하기 위해 Ron과 팀은 최신 OS에서 보안 및 백업 소프트웨어의 최종 컬렉션을 지원 패치와 통합하는 것과 관련된 여러 테스트 사례를 건너 뛰었습니다. 시뮬레이션 된로드는 새로 생성 된 서버에서 처음으로 발생했으며 커널 버그, CPU 및 메모리 프로비저닝 문제, 스토리지 레이아웃 및 용량 문제 등 Ron의 아키텍처 내에서 일련의 문제가 발생했습니다. 이 프로젝트는 고객 신뢰, 적절한 테스트 및 검증, 크기 조정 및 아키텍처를 해결하고 소프트웨어 및 OS 수정 사항을 적용하기 위해 4 주 이상 지연되었습니다. 클라우드의 약속은 매력적이며 잘 계획된 클라우드 마이그레이션을 통해 귀하와 귀하의 팀은 이러한 이점을 활용할 수 있습니다. 클라우드 마이그레이션을 시작하든 중간에 있든이 기사가 일반적인 함정을 더 잘 인식하여 피할 수 있기를 바랍니다. – Cassius Rhue, 고객 경험 담당 부사장 SIOS에서 재현

Results 1-5 of 622
Page 1 of 125 >

우리의 메일 링리스트에 가입하세요

First Name Last Name Email Address
수색