비디오 관리 시스템(VMS)에 고가용성(HA)이 필요한 이유
이번 Let’s Talk 에피소드에서는 SIOS Technology의 수석 기술 전문가인 데이브 버밍엄이 보안 애플리케이션을 위한 비디오 관리 시스템(VMS)에서 고가용성(HA)의 중요성에 대해 논의하며, 필수 구성 요소를 보호하는 등의 과제에 초점을 맞춥니다.
허가를 받아 재생산되었습니다.시오스
SIOS SANless clusters High-availability Machine Learning monitoring
이번 Let’s Talk 에피소드에서는 SIOS Technology의 수석 기술 전문가인 데이브 버밍엄이 보안 애플리케이션을 위한 비디오 관리 시스템(VMS)에서 고가용성(HA)의 중요성에 대해 논의하며, 필수 구성 요소를 보호하는 등의 과제에 초점을 맞춥니다.
허가를 받아 재생산되었습니다.시오스
기업은 유연성과 확장성을 유지하기 위해 여러 클라우드 서비스 제공업체를 점점 더 많이 사용하고 있습니다. 그러나 CrowdStrike 중단과 같은 최근 사건은 최고 시스템조차도 특히 업데이트 및 보안 패치와 관련하여 문제가 발생할 수 있음을 보여줍니다. 이 웨비나에서는 예기치 않은 중단 중에 미션 크리티컬 애플리케이션을 작동 상태로 유지하기 위해 다중 클라우드 고가용성(HA) 솔루션을 구현하기 위한 모범 사례를 설명합니다. 또한 시스템 구성 오류나 문제가 있는 패치로 인한 가동 중지를 방지하여 클라우드 인프라를 효과적으로 관리할 수 있는 전략도 다룹니다.
온디맨드 웨비나를 시청하고 사용자 환경에서 HA를 달성하고 예방 가능한 가동 중지 시간을 최소화하는 방법을 알아보세요.
허가를 받아 재생산되었습니다.시오스
제가 전차대대에서 복무하던 해병대였을 때, 투사체를 쏘기 직전에 “구멍에서 총이 난다”는 소리를 들을 준비를 했던 걸 기억합니다. 다른 사람들이 이렇게 소리치는 걸 듣지 못했더라도, 우리는 무전기/통신, 손/팔 신호, 깃발, 플레어 등을 통해 모든 것이 “진행 중”이고 투사체가 사정거리 내로 향하고 있음을 알렸습니다. 우리 모두는 의사소통이 필수적이라는 걸 알고 있었습니다.
클러스터의 애플리케이션 리소스 상태를 담당하는 데이터베이스 관리자, 서버 엔지니어 또는 IT 전문가인 경우(데이터키퍼스토리지), 커뮤니케이션은 여러분에게도 필수적입니다. 예를 들어, 스토리지를 확장하려는 노력에 대해 다른 사람들에게 어떻게 알리나요? 성공하려면 소스 및 대상 볼륨과 관련된 광범위한 주제에 대해 팀의 다른 여러 멤버와 커뮤니케이션해야 할 가능성이 높습니다. 여기에는 다음이 포함됩니다.
기존 DataKeeper Mirror(s)를 프로비저닝할 때 “FIRE IN THE HOLE”이라고 소리칠 팀원은 누구입니까? 그 전과 후에 알림을 받고 싶지 않으신가요?
DataKeeper Storage에는 내부 또는 외부(호스팅)로 모든 이해 관계자에게 전달해야 하는 몇 가지 사항이 필요합니다.
해병: “준비 되셨나요?”
다른 해병대원들: “예!” (물론 욕설이 섞여 있지만, 우리는 해병대원이에요! ㅋㅋㅋ)
해병: “구멍에 불이 났어요”
DataKeeper 관리자: “미러 일시 중지 및 잠금 해제” 또는 “구멍 속의 불”
고가용성을 위해 스토리지를 최적화할 준비가 되셨나요?SIOS 전문가와 연결오늘 귀하의 클러스터 크기 조정이 원활하고 효율적이며 확장 가능하게 구축되었는지 확인하세요.
허가를 받아 재생산되었습니다.시오스
고객 지원 조직으로서, 우리는 매일 전 세계 고객으로부터 소식을 듣습니다. 고객은 질문이 있거나 도움이 필요한 문제가 있을 때 전화나 이메일을 통해 사례를 엽니다. 일부 사례는 새로운 문제가 되고 많은 사례는 전혀 새로운 문제가 아닙니다. 고객은 같은 문제에 계속 부딪히는 듯합니다. 고객 지원 분야에서 20년 동안 일한 후에도 수천 건의 사례를 접했지만, 우리는 여전히 전에 보고된 적이 없는 새로운 문제를 보고 있으며, 이러한 문제도 일반적인 범주에 속합니다. 이로 인해 우리의 업무는 매우 흥미로워집니다! 우리가 알아차린 한 가지는 고객이 보고한 문제가 속하는 일반적인 범주가 있다는 것입니다.
고객이 도움을 요청하는 상위 5가지 이유(근본 원인)는 다음과 같습니다.
고객은 클러스터에서 IP 주소를 변경해야 하는 경우가 많습니다. 때로는 네트워크 구성을 변경하는 결과가 미리 실현되거나 계획되지 않습니다. 네트워크가 변경되면 클러스터에서 예상치 못한 문제가 발생할 수 있습니다. 변경된 IP 주소가 미러 엔드포인트나 통신 경로와 같은 DataKeeper 및 LifeKeeper 구성에서 사용되는 경우 DataKeeper 및 LifeKeeper 구성을 변경하여 제품이 이 변경 사항을 인식하도록 해야 합니다.
미리 계획하세요
네트워크 변경이 필요하다는 것을 알고 있다면 네트워크 변경을 미리 계획하는 것이 좋습니다. 미리 계획하면 예상치 못한 문제를 피할 수 있고 변경을 구현하기 위한 정의된 단계가 있는지 확인할 수 있습니다.
미러 IP 주소 업데이트
IP 주소(미러 엔드포인트)가 변경되면 DataKeeper는 더 이상 원래 미러 IP 주소를 사용할 수 없게 되고(더 이상 존재하지 않으므로) 서버 간에 데이터를 미러링할 수 없게 됩니다. DataKeeper는 새 미러 IP 주소를 사용하도록 업데이트해야 합니다. 이 시나리오는 문서화되어 있습니다.여기.
종종 보고된 문제의 근본 원인은 구성 문제입니다. 고객은 구성이 제대로 작동하지 않거나 제품 GUI에서 보고 있는 것과 달리 제품이 제대로 작동하지 않는 것처럼 보인다고 보고합니다. 일반적으로 구성 문제는 원래 클러스터 구성에서 클러스터 환경에서 변경된 사항이나 제품을 처음 설치할 때 올바르게 설정되지 않은 사항으로 인해 발생합니다.
보고된 일반적인 구성 문제의 예:
고객은 볼륨을 확장/성장해야 하는 경우가 많습니다. 주요 제품 요구 사항 중 하나는 소스 볼륨이 대상 볼륨과 같거나 작아야 한다는 것입니다. 그렇지 않으면 제품이 소스에서 대상 볼륨으로 데이터를 다시 동기화할 수 없습니다. 이는 논리적으로 보일 수 있지만 종종 간과됩니다. 때로는 대상 볼륨이 소스보다 작아져서 볼륨이 미러링 상태에 도달할 수 없게 됩니다. 다음 설명서와 비디오에서는 볼륨을 확장하는 절차를 설명합니다.DataKeeper 볼륨.
DataKeeper를 설치할 때 사용자는 DataKeeper 서비스에서 사용할 로그인 자격 증명을 입력하라는 메시지를 받습니다. 관리자 권한이 있는 도메인 계정이 권장되며 대부분의 고객은 DataKeeper에서 사용할 계정을 특별히 만듭니다. 사용되는 도메인 계정은 로컬 시스템 관리자 그룹에 추가해야 합니다. 이 계정은 DataKeeper가 설치된 각 서버에서 관리자 권한이 있어야 합니다. 많은 경우 계정이 로컬 시스템 관리자 그룹에 추가되지 않아 DataKeeper가 클러스터의 자체 및 다른 DataKeeper 서버에 연결할 수 없습니다. 자세한 내용은 설명서를 참조하십시오.여기.
대부분의 경우 구성 문제로 인해 DataKeeper 또는 LifeKeeper 제품을 다시 작동 환경으로 되돌리려면 클러스터를 변경해야 합니다.
클러스터 환경을 변경하기 전에 지원팀에 문의하여 올바른 방향으로 가고 있는지 확인하는 것이 좋으며, 해당 주제에 대한 설명서와 비디오를 안내해 드립니다.
업그레이드는 시스템 관리자의 업무에서 흔한 부분입니다. 새로운 버전이 출시되면 항상 시스템에서 무언가를 업그레이드해야 합니다. 운영 체제, 애플리케이션 소프트웨어, 시스템 펌웨어, 데이터베이스 소프트웨어, 보안 소프트웨어 등입니다. 시스템에서 수행해야 할 업그레이드가 여러 개 있는 경우 압도적일 수 있습니다.
많은 고객이 DataKeeper 또는 LifeKeeper를 업그레이드할 계획일 때 지원팀에 연락하여 업그레이드를 실제로 구현하기 전에 업그레이드 프로세스를 이해했는지 확인하기 위해 질문을 합니다. 이것이 우리가 보고 싶은 것입니다. 일부 고객이 업그레이드를 수행하기 전에 연락하지 않아 예상치 못한 문제가 발생하는 경우도 있습니다. 많은 사람이 업그레이드가 일상적이라고 생각하지만, 비호환성을 발생시키고 문제를 일으킬 수 있는 업그레이드도 있습니다.
업그레이드 계획
업그레이드에는 계획이 중요하며 특정 업그레이드가 무엇을 수반하는지 이해해야 합니다. 업그레이드를 수행하기 전에 질문하십시오. 업그레이드 전에 단계를 문서화했는지 확인하십시오. 프로덕션 시스템을 업그레이드하기 전에 테스트 또는 QA 시스템에서 업그레이드를 수행하는 것을 잊지 마십시오. 이것은 업그레이드에 문제가 발생하더라도 테스트 서버 또는 QA 서버에서 문제가 발생하고 프로덕션 서버에서는 문제가 발생하지 않도록 권장하는 모범 사례입니다.
외부 또는 OS 관련 문제는 무엇입니까? 보고된 문제가 DataKeeper 및 LifeKeeper 영역 외부에 있는 것으로 판명될 때 근본 원인을 외부 또는 OS 관련 문제라고 합니다. DataKeeper 및 LifeKeeper는 디스크/볼륨 및 네트워크와 같은 많은 서버 구성 요소를 사용합니다. 운영 체제가 디스크나 볼륨을 “볼” 수 없으면 DataKeeper 및 LifeKeeper도 디스크나 볼륨을 “볼” 수 없습니다. 보고된 문제는 언뜻 보기에 DataKeeper 또는 LifeKeeper와 관련된 것처럼 보일 수 있지만 문제를 분석하면 DataKeeper 또는 LifeKeeper가 의존하는 운영 체제 구성 요소로 판명됩니다.
예를 들어, DataKeeper 미러가 제대로 작동하려면 DataKeeper에서 볼륨이 운영 체제에서 볼 수 있고, 온라인 상태이며, 정상 상태이고, 유효한 파일 시스템이 있어야 합니다. 이러한 요구 사항이 충족되지 않으면 DataKeeper 미러가 한 시스템에서 다른 시스템으로 데이터를 미러링할 수 없습니다. DataKeeper는 미러가 일시 중지됨 상태임을 표시합니다. 이 문제를 디버깅할 때 디스크/볼륨에 대한 Windows 디스크 관리 도구는 볼륨이 오프라인 상태이거나 정상 상태가 아니거나 원시 장치임을 표시합니다. 이를 수정하면 DataKeeper가 한 시스템에서 다른 시스템으로 다시 데이터를 미러링할 수 있습니다. 자세한 내용은 DataKeeper 사용을 위한 스토리지 준비 비디오를 참조하십시오.여기.
외부 또는 OS 관련 문제의 또 다른 예는 DataKeeper 볼륨이 대상 시스템에서 잠기지 않을 때 발생합니다. DataKeeper는 대상 시스템에서 쓰기가 발생하지 않도록 의도적으로 볼륨을 잠급니다. DataKeeper가 대상 볼륨을 잠그려면 볼륨에 OS 페이지 파일이 없어야 합니다. 많은 경우 시스템은 OS 수준에서 “페이징 파일을 자동으로 관리”하도록 구성되고 때로는 OS에서 페이지 파일이 DataKeeper 볼륨에 배치됩니다. 이를 극복하려면 이 OS 설정을 변경하는 것이 좋습니다. 참조이 링크자세한 내용은.
고객은 미러가 미러링 상태로 전환되지 않거나 제품이 시스템 성능을 저하시키기 때문에 미러링으로 미러 성능과 시스템 성능을 개선하기 위해 저희에게 문의하기도 합니다. 첫 번째 문제(미러가 미러링 상태에 도달하지 못함)는 WriteQueueHighWater, WriteQueueHighWaterSynchronous, BlockWritesonLimitReached와 같은 튜너블을 사용하여 DataKeeper의 레지스트리 키를 시스템 구성과 일치하도록 조정하는 문제일 뿐입니다. 이러한 튜너블에 대한 설명서를 참조하세요.여기.
두 번째 문제(시스템 성능)는 단순히 DataKeeper 비트맵의 위치를 옮기는 문제입니다. 기본적으로 비트맵은 C 드라이브에 있으며 더 빠른 드라이브로 옮겨야 할 수도 있습니다. 비트맵을 옮기는 방법에 대한 정보는 설명서와 비디오를 참조하십시오.여기.
시스템 및 제품 튜닝은 종종 성능을 극대화하기 위해 수행됩니다. 이러한 변경의 예로는 고객 환경과 더욱 밀접하게 일치하도록 제품 튜닝 가능 항목을 변경하는 것이 있습니다. 운영 체제, 네트워크, 스토리지 장치 등을 포함하여 DataKeeper 및 LifeKeeper에 영향을 미칠 수 있는 많은 요소가 있습니다. DataKeeper 및 LifeKeeper는 고객의 특정 환경에 맞게 조정해야 할 수 있는 기본 설정을 사용합니다. 고객이 HA 모범 사례가 구현되었는지 확인할 수 있도록 검증 및 상태 점검 서비스를 제공합니다. 방문이 링크자세한 내용은 당사에서 제공하는 상품을 참조하세요.
우리가 추천하는 핵심 전략은 성능 문제를 포함한 문제가 프로세스 초기에 발견되어 해결되도록 프로덕션에 들어가기 전에 테스트를 완료하는 것입니다. 테스트는 종종 프로덕션 환경으로 들어가기 전에 테스트 또는 QA 환경에서 수행됩니다. 프로덕션 환경이 충분히 수행되는지 확인하기 위해 테스트/QA 환경에서 프로덕션 환경 부하를 시뮬레이션하는 것이 항상 가장 좋습니다. 성능에 대한 여러 블로그를 읽어 보는 것이 좋습니다.우리의 블로그그리고 특히여기.
이러한 일반적인 문제를 미리 파악하여 시스템이 원활하게 실행되도록 하세요. 전문가의 안내가 필요하신가요?오늘 당사 지원팀에 문의하세요향후 지원 전화를 받지 않도록 도와드립니다!
허가를 받아 재생산되었습니다.시오스