SIOS SANless clusters High-availability Machine Learning monitoring
SIOS 수석 제품(Windows) 지원 엔지니어인 Greg Tucker가 이 3분 분량의 비디오에서 올바르게 제거하는 방법을 보여줍니다. SIOS 데이터 키퍼 저장 SIOS LifeKeeper에서.
DataKeeper를 제거하기 전에 클러스터에서 DataKeeper 리소스를 제거하는 것이 좋습니다.
비디오 끝에서 Greg는 다른 질문이나 문제가 있는 경우 SIOS 지원 연락처 정보를 공유합니다.
SIOS LifeKeeper에서 SIOS DataKeeper 스토리지를 제거하는 방법 | 시오스 SIOS의 허가를 받아 재생산
어떤 식으로든 2020년과 2021년의 세상을 바꾸는 사건은 우리가 알고 있던 거의 모든 것을 재편성했습니다. 고가용성 많은 회사가 클라우드 채택 여정을 빠르게 추적했기 때문에 예외는 아닙니다. 폐쇄 및 제한에도 불구하고 많은 IT 팀은 온프레미스 데이터 센터를 클라우드로 전환했습니다. 많은 사람들이 '이제 어떻게 합니까?2022년 클라우드 여정을 수정하기 위해 해야 할 5가지 사항은 다음과 같습니다.
클라우드로의 전환 과정에서 많은 IT 및 비즈니스 리더는 COVID-19로 인해 폐쇄된 데이터 센터에서 클라우드로 서비스와 애플리케이션을 이동하기 위해 서두르고 있음을 알게 되었습니다. 다른 사람들은 데이터 센터 폐쇄 때문이 아니라 원격 근무의 갑작스러운 증가로 인한 폭발적인 수요의 물결에 대처하기 위해 클라우드로 돌진했습니다. 어떤 사람들에게는 클라우드로의 여정이 너무 빨라서 고가용성이 포함되지 않았습니다. 이제 그들은 애플리케이션이 여전히 클라우드에서 충돌하고 예기치 않은 중단과 계획되지 않은 다운타임이 여전히 AWS의 천적이라는 것을 (힘들게) 발견했습니다. Azure 및 GCP – 이전 데이터 센터에 있었던 것과 동일합니다.
클라우드 여정을 수정하는 첫 번째 단계는 고가용성을 추가하는 것입니다. 이는 기업에 다음과 같은 몇 가지 의미가 있습니다.
물론 모든 사람이 어떤 형태의 클라우드를 고려하지 않고 클라우드로 전환한 것은 아닙니다. 고가용성 . 일부 IT 팀은 HA를 온프레미스로 두지 않을 것을 예견했지만 클라우드로 급하게 이동하면서 중요한 모든 서버를 동일한 클라우드 가용 영역으로 옮겼습니다. 완전한 취약성보다 일부 HA 보호 기능이 있는 것이 좋지만 단일 가용 영역(AZ)에만 서버와 애플리케이션을 배포했다면 이제 대기 클러스터 노드에 대해 다중 AZ로 확장하거나 구축해야 할 때입니다. 다른 지역에 세 번째 노드를 배포하여 재해 복구.SIOS는 수십 명의 고객이 다중 AZ 아키텍처를 계획하고 재해 복구 솔루션.
하룻밤 사이에 일부 회사와 IT 팀은 완전한 온프레미스에서 Cloud Formation 템플릿, 빠른 시작 가이드, IAM 역할, 내부 로드 밸런서, 오버레이 IP와 씨름하고 VM 크기가 정확히 무엇을 의미하는지 해독하기 위해 노력했습니다.이제 클라우드로의 여정을 지원할 팀을 구성할 때입니다.이것은 여러 가지를 의미합니다: ㅏ. 용량 추가.완전한 리프트 앤 시프트를 수행할 수 없다면 클라우드 및 온프레미스 애플리케이션을 관리하는 동일한 직원이 있을 것입니다.레거시 솔루션은 변덕스럽고 안정적이고 가용성을 유지하기 위해 많은 작업이 필요한 것으로 알려져 있습니다. 앞서 클라우드 여정을 탐색하려면 가용성 요구 사항을 해결하고, 클라우드 아키텍처를 이해하고, 엔터프라이즈 요구 사항에 맞게 향후 과정을 계획할 수 있는 용량이 필요합니다.
비. 훈련을 통한 스킬 강화 .IT 팀에게 클라우드에 대한 교육을 제공하십시오.향후 과정을 관리하고 계획하려면 클라우드 솔루션, 아키텍처, 모범 사례 및 장단점에 대한 추가 교육을 통해 조직 내에서 IT 우수성을 강화할 방법을 찾으십시오.자신있게 훈련된 직원은 가용성 증가로 배당금을 지급할 뿐만 아니라 경제적이고 확장 가능하며 논리적인 방식으로 가용성, 유지 관리 및 성장을 해결함으로써 배당금을 지급할 것입니다.번역: 나머지 클라우드 인프라를 구축할 때 비용 낭비를 방지합니다.
SIOS Technology Corp의 고객 경험 부사장 저는 HA, DR 또는 해당 팀을 희생하지 않고 2021년에 클라우드로 전환한 여러 회사와 협력했습니다. 필요한 가동 시간(99.99%)을 달성하는 것을 진지하게 생각하고 협상할 수 없는 재해 계획이 있다면 엄격한 분석 및 추가 모니터링을 추가해야 할 때입니다. 가용성 솔루션에 재해 또는 계획되지 않은 다운타임 발생 시 복구를 위한 애플리케이션 인식 자동화 및 오케스트레이션이 있는지 확인합니다. 분석 및 자동화를 추가하여 솔루션을 강화하고 클라우드 마이그레이션을 사후 장애 조치 중 하나에서 오류가 발생하기 전에 사전 알림 및 장애 완화에 이르기까지 한 단계 업그레이드하십시오.성능이 저하된 애플리케이션이나 증가하는 대기 시간, 오류 또는 VM 무응답 동작에 대한 알림을 제때 수신하여 비즈니스 피크 시간에 다운타임을 방지한다고 상상해 보십시오. 분석은 원래 가용성 아키텍처에서 벗어날 수 있는 시스템과 애플리케이션을 드러낼 수 있기 때문에 중요합니다.
우리가 실패라고 생각하는 많은 것들이 프로세스의 실패에 뿌리를 두고 있습니다. 조직의 프로세스가 최신 상태이고 문서화되어 있으며 적절하게 전달되고 준수되는지 확인하십시오. 이러한 프로세스에는 누가, 무엇을, 언제, 어디서, 어떻게 모두가 고객과 관련된 비즈니스 전략, 목표 및 조직 요구와 연결되는지와 관련된 몇 가지 핵심 최소값이 포함되어야 합니다.
새 클라우드 환경에 대한 소유권 및 승인 프로세스가 문서화되어 있는지 확인하십시오. 인프라를 확보하는 하드웨어 팀에서 클라우드 팀으로 이동한 고객의 역할과 책임이 상충되거나 충돌하거나 해결되지 않아 발생하는 좌절감을 직접 목격했습니다. 마이그레이션을 통한 혼란은 일련의 고충 중 하나이며 명확한 거버넌스 없이 재해를 파헤치는 것은 훨씬 더 크고 비용이 많이 드는 문제입니다.
클라우드로 도약했다면 거기에 머물면서 클라우드를 작동하게 만드는 것이 여정의 다음 부분입니다.클라우드 여정이 갑작스럽거나 불안정한 경우 클라우드 여정을 개선하기 위해 다음 5가지 사항을 고려하고 SIOS 기술이 클라우드에서의 고가용성뿐만 아니라 클라우드에서 실행하기 위한 프로세스를 개선하는 데 도움이 될 수 있음을 알아두십시오.
-Cassius Rhue, VP, 고객 경험 복제 시오스
SIOS 수석 제품(Windows) 지원 엔지니어인 Greg Tucker는 2노드 시스템의 미러 .
또한 그는 다음과 같이 논의합니다.
튜토리얼이 완료되면 Greg는 추가 질문이나 문의에 대한 모든 SIOS 지원 연락처 정보를 공유합니다.
한 네트워크에서 다른 네트워크로 미러를 이동하는 방법 | 시오스 의 허가를 받아 재생산 시오스
모든 규모의 기업에서 IT 시스템에 대한 수요가 계속 증가하고 있다는 것은 비밀이 아닙니다. 그러나 IT 시스템은 운영, 탄력성 및 고가용성인 경우에만 이러한 비즈니스와 고객에게 효과적입니다. 기업이 기업 가용성을 구축하려고 할 때 취약성을 평가하고 평가하기 위한 기준선을 갖추는 것이 인프라, 소프트웨어, 서비스 및 지원을 성공적으로 통합하여 성공을 증가시키는 차이가 될 수 있습니다.
때로는 가장 기본적인 체크리스트가 솔루션의 가용성 또는 취약성 여부를 분류하는 데 도움이 될 수 있습니까?
그들은 소프트웨어를 배포하지만 네트워크 인프라, 서버 및 데이터 센터 자체 내에서 불안정합니다. 클라우드는 많은 인프라 문제를 해결하지만 모든 클라우드 플랫폼이 동일하게 설계되는 것은 아닙니다. 데이터 센터, 온프레미스 또는 클라우드를 이해해야 합니다.
런북 또는 플레이북이 무엇인지 대답했다면 첫 번째 단계는 런북 또는 플레이북을 찾거나 만드는 것입니다. Runbook(또는 플레이북)은 조직이 고가용성 시스템 아키텍처와 관련하여 시스템 및 프로세스를 유지 관리하는 데 도움이 됩니다. 일부 회사는 자동화된 도구를 사용하여 서버를 배포 및 구성하는 스크립트를 생성하고, 다른 회사는 버전 제어 문서를 사용하여 복원력과 성공을 제공하기 위해 모든 것이 함께 작동하는 방법을 설명합니다. 당신의 팀은 새로운 사람들과 기존 팀원들이 사용되는 환경, 프로세스 및 도구를 이해하기 위해 갈 수 있는 장소가 필요합니다.
IT 관리자는 "이 시스템을 설정한 것이 아닙니다"라고 말했습니다. 애도는 정직하고 조직에서 자주 관찰되는 현상이었습니다. 인수합병, 비용 절감, 아웃소싱 또는 일반 직원 이직의 결과이든, 고가용성 기업의 핵심 구성 요소는 충분한 인력입니다. 매우 취약한 기업의 핵심은 인력 부족, 교육 부족 또는 지원 부족입니다.
변경 관리가 중요합니다. 변경 관리 제어 및 정책은 위험을 줄이고 시스템을 사용할 수 있도록 하는 데 절대적으로 필요합니다. 적절한 제한이 없는 사용자는 안정성을 파괴하는 패키지 또는 업데이트를 추가하거나 몇 시간 동안 조직을 방해하는 변경을 수행할 수 있습니다. 또한 정의된 정책이 없으면 종종 예상(문서화)과 실제(적소에 있는) 사이에 드리프트가 발생합니다. 변경 관리는 또한 대기 클러스터가 기본/소스 시스템과 동일한 패치 및 소프트웨어 수준에 있고 QA(또는 사전 프로덕션)가 프로덕션에서 크게 벗어나지 않도록 하는 데 중요합니다.
우리 서비스 팀은 고객 통화에 참여하여 소프트웨어를 구성 및 업데이트하기 위해 세션에 참여하기 위해 일련의 상승된 명령을 실행할 수 있는 권한이 있는 관리자를 기다리고 기다리고 기다렸습니다. 몇 주 후, 우리 팀은 다른 고객 통화에 합류했고 모두 관리 권한이 있는 여러 사용자가 동일한 클러스터에서 수많은 명령을 실행하는 것을 공포에 떨었습니다. 두 호출의 차이점은 액세스 제어가 중요하다는 것을 놀랍도록 명확하게 지적했습니다. 고가용성 기업은 구성을 손상시키거나 작업을 감소시킬 수 있는 상승된 명령을 사용자가 실행하지 못하도록 적절한 액세스 제어가 마련되어 있는지 확인해야 합니다. 사용자가 자신의 역할, 요구 사항 및 경험에 따라 수행할 수 있는 작업에 제한이 있는지 확인합니다.
테스트에는 시간이 걸리지만 고객의 클라우드 마이그레이션 및 고가용성 배포 , 시간은 항상 잘 보냈습니다. 종종 고가용성과 취약성의 차이는 고객이나 파트너의 테스트 프로세스로 귀결될 수 있습니다. 솔루션이 더욱 복잡해짐에 따라 위험과 취약성을 줄이기 위해 테스트와 검증이 점점 더 중요해지고 있습니다. 모든 것이 설계에서 생산에 이르는 경우 매우 취약한 시스템을 실행하고 있는 것입니다. 그러나 테스트와 체크포인트가 있는 경우 프로덕션에 적용하기 전에 변경 사항을 확인하는 프로세스가 크게 줄어듭니다. 고객 경험 담당 부사장으로서 우리 서비스 팀은 실제 마이그레이션을 완료하기 전에 QA에서 1년 내내 시스템을 배포한 배너 고객과 협력했습니다. 그 해 동안 그들은 정전, 재해, 고객 부하, 가동 중지 시간, 유지 관리, 패치 전략, 백업, 백업에서 복구 및 기타 여러 테스트 제품군을 시뮬레이션했습니다. 결과적으로 성능, 프로세스 준수, 고가용성 및 기업 성공에서 놀라운 결과를 얻었습니다.
고가용성의 모든 잠재적인 취약점을 다룰 수 있는 체크리스트는 없지만 이러한 질문에 답하면 기업이 고가용성인지 아니면 매우 취약한지 이해하기 위한 강력한 토대가 됩니다.
의 허가를 받아 재생산 시오스
주말 동안 나는 Disney의 Encanto를 시청하고 이야기의 팬이 되었고 수업과 기회의 학생이 되었으며 Lin-Manuel Miranda의 절대적인 팬이 된 많은 사람들과 합류했습니다. 고가용성, 클러스터링 및 복원력과 관련하여 Disney의 Encanto는 무엇을 제공합니까?
에 대한 수업 고가용성 , IT 팀 및 Disney의 Encanto에서 다운타임 방지[Warning: movie spoilers ahead] Encanto에서 당신은 Family Madrigal이 특별한 가족이라는 것을 빨리 알게 됩니다. 오프닝 곡 중 하나인 "Family Madrigal"에서 우리는 가족 구성원 모두가 독특하고 특별한 선물을 가지고 있음을 이해합니다. 초인적인 힘, 먼 곳까지 들을 수 있는 능력, 예언과 예측, 아름다운 꽃과 식물을 불러일으키는 능력, 형태를 바꾸는 능력, 치유하는 능력, 날씨를 조절하는 능력. 글쎄요, 미라벨을 제외하고는 모두가 '선물'을 가지고 있는 것 같습니다.
Mirabel은 다른 형제 자매 및 가족 구성원처럼 재능이 없지만 가족의 건강과 질병을 이해하는 중심 인물입니다. 게다가 그녀는 가족이 모든 것이 무너졌을 때 다른 선물 없이 물건을 다시 제자리에 맞추도록 도울 수 있습니다. 고가용성이 필요하지만 이를 달성하기 위해 예산을 초과하거나 초자연적인 능력을 개발하거나 기적에 의존할 필요가 없습니다.
영화가 계속되면서 페파의 막내아들 안토니오는 선물을 받을 준비를 하고 있다. 그러나 파티와 축하 행사에서 Abuela는 Casita의 기초에 균열이 있음을 알게 됩니다. 그러나 그녀의 경고는 무시됩니다.
미라벨은 균열을 발견하고 카시타를 위험에 빠뜨리는 것이 무엇인지, 그리고 어떻게 도울 수 있는지 알아내기 위해 그녀를 안내합니다. 처음에는 남들에게 무시당하고 질책을 받기도 한다. IT 인프라에 균열이나 단점이 있거나 아키텍처와 설계에 균열이 있는 경우 어떻게 대처하시겠습니까? 균열을 무시하거나, 보이지 않는 척하거나, 발견한 팀을 책망하시겠습니까? 균열을 무시하지 마십시오. 문제의 첫 징후에 대응하는 것이 더 큰 문제를 예방하는 가장 완벽한 방법입니다.
답을 찾고 기적의 마법을 구하려는 여정에서 돌로레스는 미라벨에게 초강력 누나 루이사와 이야기를 나누라고 말합니다. 루이사는 처음에 모든 것이 정상이고 아무 잘못이 없다고 제안합니다. 그러나 Luisa는 마침내 그녀가 혼자 짊어지기에는 짐이 있다는 것을 아는 것의 무게가 너무 커지고 있음을 밝히기 시작합니다.
Luisa가 말했듯이 "낙타의 등이 부러지는 것은 압력, 결코 멈추지 않을 것입니다.". 고가용성 솔루션 개발, 복원력 및 데이터 가용성을 위한 설계 및 아키텍처는 단순한 프로세스가 아니며 확실히 한 사람 또는 단일 팀의 작업이 아닙니다. DBA, IT 관리자 및 ERP 관리자는 중요한 엔터프라이즈 가용성을 혼자 유지하는 무게를 감당할 수 없습니다. 마찬가지로, 1차원 접근 방식은 가용성의 99라는 무게를 감당할 수 없습니다. 대신 도구와 기술을 이해, 설계, 개발 및 배포하기 위해 완전한 HA 솔루션과 협력하여 완전히 정렬된 팀이 필요합니다. IT 팀의 역할과 책임이 얼마나 잘 분산되고 정의되어 있습니까? HA 단독으로 책임을 지는 사람이 없도록 하십시오.
미라벨이 브루노가 찾고 있는 답을 찾으면 모두가 "우리는 브루노에 대해 이야기하지 않습니다"라고 말합니다. 브루노의 재능은 예지력이지만 그의 경고와 부정적으로 보이는 비전 때문에 그는 사라졌습니다.
고객 경험 부사장으로서 저는 고객이 인프라 및 클러스터링 솔루션에 대한 상태 평가를 수행하도록 도왔습니다. 상태 확인이 완료되었을 때 모든 고객이 해결해야 할 문제가 있다는 소식에 기뻐하는 것은 아닙니다. 우리 모두는 나쁜 소식을 피하기 위해 최선을 다합니다. 그러나 업그레이드를 무시하고 유지 관리를 잊고 팀의 Bruno가 식별한 위험을 경시한다고 해서 문제가 사라지지는 않습니다. 사실, 그것은 당신의 최악의 두려움을 현실로 만들 수 있습니다.
미라벨은 결국 브루노로 가는 비밀 통로를 발견하고 브루노가 결코 떠나지 않았다는 것을 발견하지만 그녀와 자신을 보호하기 위해 그녀의 시야를 파괴해야 한다고 느꼈다.
당신의 문화는 더 높은 가용성과 탄력성을 위한 공간을 부수거나 만들 수 있습니다.
미라벨은 브루노에게 카시타의 크랙을 패치한 적이 있는지 묻지만 브루노는 크랙이 두렵다고 대답한다.
HA에는 지속적이고 조정된 지속적인 노력이 필요합니다. 노력의 필수적인 부분은 애플리케이션이나 아키텍처와 실행 간의 격차를 위태롭게 할 수 있는 IT 균열에 대한 솔루션과 수정 사항을 찾는 것입니다.
Bruno(또는 Hernando)가 균열을 패치하려고 시도하더라도 근본적인 문제가 spackle 및 피상적인 솔루션에 너무 많다는 것이 분명합니다.
인프라를 살펴보고 문제가 해결되는 방식을 살펴보십시오. 대안, 반창고 및 임시 "해킹"을 배포하고 있습니까? 아니면 클러스터, 엔터프라이즈 가용성 및 재해 중 실행 문제의 근본 원인을 해결하는 아키텍처 및 기본 솔루션을 찾고 있습니까?
근본 원인 솔루션보다 더 많은 핵과 해결 방법을 배포했다면 Jorge를 찾으십시오. 숙련된 팀 구성원, 파트너 또는 솔루션 제공자를 찾아 문제를 해결하거나 인프라를 강화할 기본 솔루션을 구현하는 데 어려움을 겪을 수 있는 권한을 부여하십시오.
브루노는 미라블이 이사벨라를 안아주면 카시타가 구원받을 수 있다는 또 다른 환상을 봅니다. Mirabel은 Isabela에게 꽃을 피울 기회를 제공하지만 Abuela는 그렇게 보지 않습니다. 미라벨과 아부엘라 사이에 논쟁이 벌어지고, 아부엘라는 '카시타'의 균열에 대해 미라벨을 탓한다. 미라벨은 불가능한 요구, 비현실적인 기대, 잘못된 희망에 대해 아부엘라를 비난합니다.
Pass Blame은 훌륭한 파티 게임이지만 HA, 클러스터 탄력성 또는 데이터 보호에는 좋지 않습니다. 나는 한 번 조직이 비난의 비생산성을 설명하는 고객을 도왔습니다. 개념 증명 클러스터에 문제가 발생하여 지연이 발생한 후 프로젝트 관리자는 지연에 대해 애플리케이션 팀을 비난했습니다. 애플리케이션 팀은 백업 관리자를 비난했고, 다시 인프라 관리자를 비난했습니다. 비난 세션 내내 그들의 클러스터는 사용할 수 없었고, 개념 증명은 계속 중단되었으며, 진행 중인 유일한 진전은 팀 사이에 커지는 분노의 균열뿐이었습니다. 이러한 차이점을 제쳐두고 문제를 해결하고 성공적인 POC를 계속하는 데 필요한 조정을 수행할 수 있었던 경우에만 가능했습니다.
'카시타'는 쓰러지고 미라벨은 도망친다. 나중에 Alma는 Mirabel을 찾고 화해한 후 가족과 마을에 합류하여 이전보다 더 나은 Casita를 다시 건설합니다.
물론 Encanto의 마지막 장면은 Alma(Abuela)의 고백에서 다음과 같은 교훈으로 가득 차 있습니다.
그러나 마지막 교훈에서 가장 중요한 것은 더 훌륭하고, 더 강하고, 함께 재건하는 것입니다. 계획되지 않았거나 계획된 모든 중단 후에는 근본 원인 분석, 경험 및 신선한 이해를 통해 교훈을 얻을 수 있습니다. 그 결과, 고가용성 및 재해 복구를 위한 더 강력한 솔루션과 아키텍처를 다시 구축할 기회도 있을 것입니다.
프로덕션에 직접 배포된 코드로 인해 중단이 발생한 것을 발견한 후 표준 배포 파이프라인 및 QA 시스템을 만들 수 있었던 고객의 경우를 생각해 보십시오. 또는 디스크 및 데이터베이스 경고가 중단되기 몇 주 전에 표시되지 않는다는 사실을 발견한 다른 고객입니다. 다운타임이 있을 때 오는 시간과 기회를 낭비하지 마십시오. 사일로, 단일 강점에 대한 의존성 또는 잘못된 것에 기반 시설의 희망을 두지 않도록 함께 협력하십시오.
물론 영화 전체를 직접 봐야 하지만 영화의 마법과 음악을 따라 걸으면서 다른 캐릭터의 삶과 교훈을 배울 때 HA에 대한 더 많은 교훈이 있습니다.
영화는 성대한 재회로 막을 내리고 미라벨과 마드리갈은 완성된 집 앞에 섰다. 미라벨이 문 손잡이를 만지면 '카시타'가 다시 살아나고 가족의 마법의 선물과 함께 집이 모두 돌아옵니다. Encanto의 고가용성을 위한 이 10가지 강의를 시도하고 영화를 즐기며 고객, 파트너, 솔루션 제공업체 및 관리자로 구성된 팀과 함께 "함께 할 수 없는 일은 없습니다."를 기억하십시오.