SIOS SANless clusters High-availability Machine Learning monitoring
이번 에피소드에서는TFiR: 이야기해 봅시다, 진행자 Swapnil Bhartiya가 다음과 같이 이야기합니다.데이브 버밍햄SIOS Technology의 고객 성공 담당 이사는 고가용성과 복원력이 왜 중요한지에 대해 다음과 같이 설명합니다.건물 유지보수 및 보안 시스템버밍햄은 이러한 시스템이 다른 건물 기술과 어떻게 다른지, 그리고 어떻게 상호 작용하는지, 또한 중단 없는 운영이 거주자의 안전과 건물 기능에 왜 필수적인지 설명합니다. 이 대화에서는 조직이 보안과 접근성 사이의 균형을 맞추는 방법, AI, 머신러닝, IoT와 같은 신기술이 신뢰성 향상에 미치는 역할, 그리고 이중화, 모니터링 및 위험 계획을 통해 시스템 가용성을 보장하는 모범 사례에 대해 살펴봅니다.
저자: 베스 윙코스키, SIOS 테크놀로지 홍보부
허가를 받아 재게재되었습니다.SIOS
모듈화와 추상화를 통한 고가용성 설계
지금까지 이 시리즈에서는 기술 설계와 수사학 사이의 유사점을 살펴보았습니다. 기술적 해결책의 “수사학”, 즉 의미와 목적을 전달하는 전략은 설계 패턴과 개념을 통해 표현됩니다. 이러한 설계 패턴과 개념은 개념적 토대를 형성하며, 그 토대 위에서 의미가 구현 과정에서 실제 적용되는 형태로 변환됩니다.
앞서 논의한 바와 같이, 이것의 연속성과 완전성은개념적 기초이는 솔루션이 유지보수, 개선 및 장기적인 신뢰성에 도움이 되는 기준을 충족하도록 보장하는 데 매우 중요합니다. 외부솔루션 설계에 영향을 미치는 요소솔루션 설계에서 제시된 개념적 기반을 유지하려는 목표에 도전하는 외부 요인들이 존재합니다. 이러한 외부 요인들은 기존 원칙과 충돌할 수 있으므로, 솔루션에 사용되는 도구, 애플리케이션 및 플랫폼은 신중하게 선택해야 합니다.
이 블로그 시리즈의 세 번째이자 마지막 부분에서는 모듈성과 추상화를 통해 경계를 설정하고, 광범위한 범위의 프로젝트가 잘 구성되고 논리적으로 타당한 디자인의 이점을 계속해서 누릴 수 있도록 하는 방법을 살펴보겠습니다.
모듈화와 추상화를 전략으로 다루기 전에, 왜 이러한 전략을 구현해야 하는지 이해하는 것이 중요합니다. 비유를 들어 설명하자면, 청중을 설득하여 자신의 계획에 동의하게 하려는 발표자는 먼저 여러 가지 핵심 논점을 제시해야 합니다. 그렇게 함으로써, 자신의 주장을 뒷받침하는 각 기둥을 제시하고 그 타당성을 입증할 수 있습니다.
화자는 먼저 “A는 B를 함의한다”와 “C는 D를 함의한다”라는 근거를 제시해야 하며, 이를 바탕으로 “B와 D는 E를 함의한다”라는 논증을 구성할 수 있다. 이 전략은 “A는 B를 함의한다”라는 추론이 “C는 D를 함의한다”라는 별개의 논점과 충돌하여 그 타당성을 훼손하지 않도록 한다. 이 전략은 화자의 논증의 각 구성 요소가 서로 독립적으로 존재할 수 있도록 해주기 때문에 자주 사용된다. 만약 “C는 D를 함의한다”라는 논증에 오류가 있더라도, “A는 B를 함의한다”라는 논증은 여전히 타당성을 유지하면서 오류를 수정할 수 있다.
이러한 구조를 갖는 이유는 기술 시스템이 분산화되는 이유와 같습니다. 즉, POS 시스템에서 발생하는 문제를 해결할 때 데이터베이스, API, 네트워크 아키텍처 등으로 해결 범위를 확장할 필요가 없기 때문입니다. 위에서 언급한 전략들은 물론 모듈화와 추상화라는 개념을 의미합니다.
첫째, 모듈성에 대해 살펴보겠습니다. 모듈성이란 자체적으로 완결된 구성 요소들로 시스템을 만드는 것을 말합니다. 수사학적 관점에서 보면, “A는 B를 함축한다”와 “C는 D를 함축한다”와 같은 논증은 전체 논증을 구성하는 추론 모듈에 불과합니다.
좀 더 기술적으로 설명하자면, 모듈화된 구성 요소(앞의 예에서 언급한 POS 시스템처럼)를 사용하면 문제가 발생한 모듈 내에서만 문제를 해결할 수 있습니다. 솔루션의 각 모듈은 빌딩 블록 역할을 하며, 단일 빌딩 블록의 문제는 전체 솔루션을 해체하지 않고도 해결할 수 있습니다.
모듈성과 밀접하게 관련된 개념이 바로 “추상화”입니다. 추상화란 전체 솔루션의 설계가 전체 솔루션을 구성하는 모듈들의 설계와 독립적이고 무관하게 이루어지도록 하는 것을 의미합니다.
또한, 추상화는 설계 전략으로서 각 모듈이 다른 모든 모듈의 설계와 독립적이며 무관하다는 것을 의미합니다. 추상화된 요소를 사용하도록 설계된 솔루션은 이러한 요소를 재사용하고 다양한 사용 사례에 적용하여 프로젝트 전반에 걸쳐 이해도를 높일 수 있습니다.
모듈형 구성 요소로 디자인을 구축할 때, 경계가 설정됩니다. 이러한 경계는 각 모듈이 다른 모듈에 방해되지 않도록 보장합니다. 구성 요소가 추상화되면 각 모듈의 내용을 더 쉽게 이해할 수 있습니다.
이러한 경계는 디자인을 이해하는 구조적 틀을 제공하며, 경계 내의 추상화는 사용 사례의 기본 원리를 이해하는 진입점이 됩니다. 모듈성과 추상화를 통해 제공되는 구조는 목적을 이해하는 틀을 제시하는 수사학의 역할과 유사합니다.
기술 솔루션이 더욱 복잡해짐에 따라, 해당 솔루션 설계에 있어 견고한 프레임워크의 필요성 또한 커지고 있습니다. 네트워크 아키텍처는 그 자체로 복잡한 여러 솔루션의 집합체인 경우가 많으며, 이러한 복잡성이 심화되는 문제와 견고한 설계 프레임워크에 대한 요구 증가를 보여주는 대표적인 사례입니다. 더욱이, 네트워크 아키텍처는 성장하는 비즈니스의 목적 달성에 기여하는 방대한 시스템들을 수용해야 하므로 지속적인 성장에 따른 문제에 직면하는 경우가 많습니다.
이러한 기반 위에 솔루션 아키텍처는 다음과 같은 솔루션을 적용해야 합니다.고가용성 및/또는 재해 복구이는 설계 충돌이 발생하기 쉬운 지점이지만, 모듈화 및 추상화 전략을 통해 쉽게 완화할 수 있습니다.
이점고가용성 소프트웨어복잡성과 편법적인 해결책 없이도 고가용성을 달성할 수 있습니다. 설계 원칙을 준수하는 고가용성 도구의 한 예인 SIOS LifeKeeper는 사용 환경에 완벽하게 통합될 수 있도록 운영 원칙이 설계되었습니다.
LifeKeeper는 모듈식 구조를 가지고 있어 LifeKeeper로 보호되는 시스템 외부에는 어떠한 요구 사항도 부과하지 않습니다. 또한 LifeKeeper는 인프라 구성 요소를 더 작은 단위로 추상화할 수 있도록 지원하며, 가용성을 보장하기 위해 함께 작동하는 시스템들을 “클러스터”로 그룹화합니다.
이러한 추상화를 통해 환경의 수사적 측면은 여전히 강력하게 유지됩니다. 즉, 하나의 클러스터 구성을 이해하는 것은 모든 클러스터를 이해하는 토대가 됩니다. 설계의 각 계층은 그 목적에 맞게 이해할 수 있으며, 설계 전반에 걸쳐 구현 방식이 어떻게 다른지에 대한 특별한 고려 사항이나 예외 조항이 필요하지 않습니다. 클러스터는 다른 클러스터나 외부 솔루션 구성 요소와 독립적으로 작동하므로, 각 계층의 설계 요소가 포함되는 경계를 설정할 수 있으며, 인프라의 다른 계층과의 충돌을 방지할 수 있습니다.
다른 소프트웨어나 도구와 마찬가지로,SIOS 보호 제품군SIOS LifeKeeper 및/또는 SIOS DataKeeper는 사용되는 환경 설계에 영향을 미칩니다. 이러한 패턴은 LifeKeeper 및 DataKeeper로 보호되는 환경을 갖추는 데서 비롯되지만, SIOS LifeKeeper와 SIOS DataKeeper는 솔루션 전체에서 추상화 및 모듈화를 가능하게 하는 패턴을 신중하게 선택했습니다. LifeKeeper와 DataKeeper가 제공하는 계층적 추상화 덕분에 이러한 유틸리티를 도입하면 솔루션 설계의 일관성을 유지하는 IT 인프라와의 통합이 용이해집니다.
적용된 설계 패턴 덕분에 SIOS Protection Suite(LifeKeeper 및/또는 DataKeeper)로 보호되는 클러스터는 기존 설계 및 솔루션에 완벽하게 통합되는 추상적이고 모듈식 요소를 구성합니다. LifeKeeper와 DataKeeper는 단일 시스템 또는 각 클러스터의 관리를 간소화하는 것 이상으로, 배포 원칙에 따라 작동합니다.
SIOS Protection Suite를 사용하면 시스템의 설계 역할을 쉽게 이해할 수 있을 뿐만 아니라 고가용성 및 재해 복구를 간편하게 구현할 수 있으므로 인프라 구축이 더욱 간소화되고 효율적입니다. 관리자는 LifeKeeper와 DataKeeper를 활용하여 향후 수년간 솔루션을 이해하고 운영하며 개선할 수 있습니다.
복잡성을 추가하지 않고도 고가용성이 인프라 설계를 어떻게 지원할 수 있는지 알아보세요.지금 바로 데모를 요청하세요!
저자: 필립 메리, SIOS CX 소프트웨어 엔지니어
허가를 받아 재게재되었습니다.SIOS
최신 애플리케이션을 관리하는 IT 팀을 위해높은 가용성을 유지합니다업데이트 배포는 어려운 과제일 수 있습니다. 안정성을 확보하는 데 있어 필수적인 요소는 품질 보증(QA) 환경과 운영 환경을 분리하는 것입니다. 이는 사소해 보일 수 있지만, 잠재적인 문제를 발견하고 유지 관리 작업에 대한 신뢰를 구축하는 데 매우 중요합니다.
QA 환경은 운영 환경의 복제본 역할을 합니다. 이를 통해 새로운 기능, 구성 변경 사항 및 패치를 철저하게 테스트할 수 있는 샌드박스를 제공합니다. 기능 테스트 외에도 QA 환경에서는 프로세스 검증, 성능 벤치마킹, 부하 테스트 및 보안 검증을 수행할 수 있습니다.
이는 최종 사용자에게 영향을 미치거나 환경을 손상시키기 전에 병목 현상, 취약점 또는 통합 문제를 식별하는 데 매우 중요한 활동입니다. 분산 시스템의 경우 또는클라우드 아키텍처QA 환경은 네트워크 지연, 데이터베이스 복제 지연 및 테스트하지 않으면 비즈니스 운영을 방해할 수 있는 기타 운영상의 예외 상황을 시뮬레이션하는 데 도움이 될 수 있습니다.
운영 환경은 최종 사용자가 시스템의 일관된 성능에 의존하는 곳입니다. 계획되지 않은 시스템 다운이나 장애는 매출 손실부터 기업 이미지 손상에 이르기까지 직접적인 비즈니스 결과를 초래할 수 있습니다.
IT 팀은 운영 환경을 개발 및 테스트 환경과 분리함으로써 운영 안정성을 보장할 수 있습니다. 적절하게 구성된 프로덕션 환경에는 다음 사항이 포함되어야 합니다.중복 전략장애 조치 메커니즘 및 모니터링 도구는 배포 전에 QA 환경에서 테스트를 통해 검증되었습니다.
고가용성은 단순히 시스템을 가동 중지시키는 것만을 의미하지 않습니다. 업데이트를 예측 가능하게 만드는 것까지 포함할 수 있습니다. QA 환경은 구조화된 배포 파이프라인을 지원하여 단계적 배포 및 블루-그린 릴리스와 같은 다양한 전략을 구현할 수 있도록 합니다. QA 환경에서 사전 검증된 롤백 절차를 통해 예상치 못한 문제가 발생할 경우 팀은 신속하게 복구할 수 있습니다. 구조화된 접근 방식은 업데이트를 예측 가능하게 만들고 고객 신뢰를 유지하는 데 도움이 됩니다.
QA 환경과 운영 환경을 분리하면 규정 준수, 감사 준비 및 팀 간 협업을 지원할 수 있습니다. 테스트 시스템과 실제 운영 시스템 간의 명확한 경계는 운영 및 개발 부서의 효율적인 협업을 가능하게 합니다. 또한 모니터링, 문제 해결 및 유지 보수를 위한 반복 가능한 프레임워크를 제공하는 데 도움이 됩니다.재해 복구 계획.
QA 환경과 운영 환경은 시스템을 원활하게 운영하는 데 매우 중요한 역할을 합니다. IT 팀은 환경을 분리하고, 철저한 테스트를 수행하며, 배포를 신중하게 관리함으로써 다운타임을 줄이고, 높은 가용성을 유지하며, 업데이트 간 전환을 원활하게 할 수 있습니다. 이러한 관행은 시스템이 발전함에 따라 신뢰성과 복원력을 유지하는 데 도움이 됩니다.
QA 및 프로덕션 환경 전반에 걸쳐 고가용성을 향상시킬 준비가 되셨습니까?데모를 요청하세요SIOS가 팀이 업데이트를 안정적으로 배포하고 중요 시스템을 계속 운영할 수 있도록 지원하는 방법을 살펴보세요.
저자: 트리스탄 알렌, SIOS 테크놀로지 고객 경험 소프트웨어 엔지니어
SIOS 의 허가를 받아 게재되었습니다.
“전원을 껐다가 다시 켜세요.” 컴퓨터 문제를 해결해 본 경험이 있는 사람이라면 누구나 한 번쯤 들어봤을 법한 조언입니다. 가장 흔한 문제 해결법으로 악명이 높으며, 이 방법만 들으면 누구나 IT 문제 해결 전문가가 된 듯한 착각을 불러일으킵니다. 하지만 문제는 이것이 실제 해결책이 아니라는 점입니다. 그저 대부분의 문제를 일시적으로 해결해 줄 뿐입니다. 전원을 껐다가 다시 켜면 일단은 빠르게 시스템을 복구할 수 있지만, 근본적인 문제의 원인은 결코 밝혀내지 못합니다.
게다가 고가용성이 중요한 환경에서는 “전원을 끄는 것” 자체가 큰 문제가 될 수 있습니다. 단 몇 분이라도 마찬가지입니다.중단 시간이는 핵심 인프라를 항상 가동 상태로 유지해야 하는 기업에게는 심각한 문제가 될 수 있습니다. 이러한 이유로 SIOS의 기술 지원팀에서는 악명 높은 이 기술 조언을 자주 하지는 않지만, 저희만의 대안은 있습니다.
SIOS에 기술 지원을 요청한 많은 사람들이윈도우 데이터키퍼미러링 문제 발생 시 “cleanupmirror” 명령어를 실행하라는 안내를 받으셨을 겁니다. 이 명령어는 적절한 상황에서 심각한 문제를 신속하게 해결하는 데 매우 유용합니다. 이 명령어는 미러 구성과 관련된 모든 잔여 파일을 완전히 삭제하여, 이전에 발생했던 문제를 해결하고 미러를 새롭게 생성할 수 있도록 합니다. 단, 이 명령어는 데이터를 삭제하는 것이 아니라 시스템 간의 복제본만 삭제한다는 점에 유의하십시오.
이 명령은 시스템 다운타임을 필요로 하지 않지만, 미러링이 재동기화가 완료될 때까지 시스템의 가용성이 낮아질 수 있음을 의미합니다. 이는 지원팀에서 자주 사용하는 문제 해결 방법 중 하나이지만, “전원을 껐다가 다시 켜보세요”와 마찬가지로 때로는 더 심각한 근본적인 문제를 가릴 수 있으며, 경우에 따라 과도한 조치가 될 수도 있습니다.
오늘은 cleanupmirror 명령어를 실행하여 고객의 당면 문제를 해결했지만, 그 과정에서 광범위한 고객에게 영향을 미칠 수 있는 심각한 문제를 놓칠 뻔했던 사례를 하나 소개하고자 합니다. 다행히도 그 문제는 아주 간단한 해결 방법으로 수정할 수 있었습니다.
지원팀이 투입되었을 때, 고객은 이미 상당한 시간 동안 문제 해결을 시도해 왔고, 패닉 상태에 빠지기 시작했습니다. 그들은 마지막 시도를 하고 있었습니다.바꿔 넣기DataKeeper 미러링에 문제가 발생하기 시작했을 때, 마이그레이션 과정의 일환으로 테스트를 진행 중이었습니다. 이 시점에서 고객의 핵심 인프라가 다운되었고, 비즈니스에 영향을 미칠까 봐 걱정했습니다. 매우 긴박한 상황이었지만, 다행히 저희 지원 엔지니어들이 훌륭하게 대처했습니다. 압박감과 시간적 제약 속에서도 최적의 해결책을 찾아냈고, 검증된 “cleanupmirror” 명령어를 실행한 후 정상적으로 작동하는 미러를 다시 생성했습니다. 덕분에 고객은 위기를 극복하고 모두 다음 단계로 넘어갈 수 있었습니다. 또한, 만일의 사태에 대비해 고객에게 로그를 보내달라고 요청하기도 했습니다.
이 사건 관련 기록은 다소 혼란스러웠습니다. 기록에 따르면 다음과 같았습니다.볼륨 크기가 조정되었습니다.하지만 고객은 통화 중에 어떠한 크기 조정 작업도 수행하지 않았다고 주장했습니다. 때때로 고객은 중요한 정보를 누락하는 경우가 있어 통화 중에 해당 세부 정보를 빠뜨렸을 가능성을 생각했지만, 크기 조정은 전혀 말이 되지 않았습니다. 크기 변경 폭은 매우 작았고, 첫 번째 스위치오버와 동시에 모든 볼륨에 적용되었습니다. 고객이 테라바이트 단위의 대용량 드라이브에서 1기가바이트도 안 되는 용량을 한 번에, 그것도 첫 번째 스위치오버와 완벽하게 동기화하여 크기를 조정했다는 것은 말이 안 되므로, 좀 더 자세히 살펴보았습니다. 그 결과, 대상 드라이브의 용량이 소스 드라이브보다 약간 더 컸고, 드라이브 크기가 일치하지 않을 때 제품 처리 방식에 문제가 있었던 것으로 밝혀졌습니다.
이 문제를 파악하고 나니, 미러링을 계속 유지하는 것만으로 해결된다는 것을 알게 되었습니다. 이는 흔하고 빠르고 간단한 작업으로, 몇 초 만에 문제를 완전히 해결할 수 있었습니다. 고가용성을 회복하기 위해 며칠씩 걸리는 재동기화 과정도 필요 없었습니다. 게다가, 이 문제를 발견한 후에는 다음 제품 버전에서 매우 빠르고 쉽게 수정할 수 있었습니다.
알고 보니 해당 고객은 특수한 마이그레이션 시나리오를 가지고 있었는데, 크기를 정확히 맞추는 것이 불가능했기 때문에 대상 시스템의 크기를 약간 더 크게 설정해야 했습니다. 아직 마이그레이션해야 할 시스템이 여러 개 남아 있었고, 만약 “미러 정리” 단계에서 문제를 해결하지 않고 그대로 두었다면 매번 같은 문제가 발생했을 것입니다. 근본 원인을 파악했기 때문에 신속하고 간편한 해결책을 제공할 수 있었고, 첫 번째 시스템 전환을 실행하기 전에 취할 수 있는 예방 조치까지 마련할 수 있었습니다. 또한, 이 해결 방법을 공개하여 다음에 같은 문제를 겪는 고객이 몇 분 안에 해결할 수 있도록 했습니다.
그렇다면 “껐다가 다시 켜세요”라는 방법의 가장 큰 문제점은 무엇일까요? 바로 근본적인 원인을 숨긴다는 점입니다. 그렇다고 해서 이 방법을 절대 사용해서는 안 된다는 뜻일까요? 여전히 가장 효과적인 기술 조언 중 하나입니다. 근본적인 원인을 알 필요 없이, 전원을 껐다가 다시 켜는 것만으로도 문제를 빠르게 해결할 수 있는 경우가 많기 때문입니다.
IT 전문가에게 중요한 점은 급한 상황에서 벗어나야 할 필요가 없고, 먼저 문제를 조사할 시간을 확보할 수 있다면 그렇게 해야 한다는 것입니다. 그렇지 않다면 나중에 로그를 확인하여 무슨 일이 일어났는지 파악하려고 노력해야 합니다.
그러니 마음껏 전원을 껐다 켜세요. 마치 마법사처럼 몇 분 만에 문제를 해결해서 모두가 어떻게 해결했는지 궁금해하게 만드세요. 하지만… 가끔은… 왜 전원을 껐다 켜야 했는지 되돌아보고, 더 쉬운 해결책이 있었을지도 모른다는 가능성을 생각해 보세요.
SIOS DataKeeper 및 고가용성 솔루션이 이와 같은 숨겨진 문제를 방지하는 데 어떻게 도움이 되는지 자세히 알아보려면 다음을 참조하십시오.데모 요청하기오늘 저희 팀에서 준비한 내용입니다.
저자: 카터 챈들러, SIOS 테크놀로지 CX 어소시에이트 겸 소프트웨어 엔지니어
허가를 받아 재게재되었습니다.SIOS
SIOS 파트너십고가용성, 클라우드 복원력 및 통합 인프라 솔루션을 구현하는 데 핵심적인 역할을 합니다.
이 팟캐스트에서해리와 켈리는 청취자들에게 마이크로소프트, AWS, 구글 클라우드와의 클라우드 제휴부터 엑사빔, 마일스톤, 심코어와 같은 전략적 ISV와의 의미 있는 협력에 이르기까지 SIOS 파트너 생태계의 내부를 소개합니다. 그들은 SIOS가 새로운 파트너를 온보딩하고 지원하는 방법, 수년간 성공적인 통합 구축을 통해 얻은 교훈, 그리고 AI, 하이브리드 클라우드, 엣지 컴퓨팅을 포함한 파트너 주도 혁신의 미래 방향에 대해 논의합니다.
이 팟캐스트는 실질적인 조언과 강력한 기술 파트너십이 비즈니스에 미치는 영향을 보여주는 성공 사례로 마무리됩니다.
허가를 받아 재게재되었습니다.SIOS