SIOS DataKeeper 볼륨 또는 미러의 크기를 조정하는 방법

이 4.5분 분량의 비디오에서 SIOS는 기존 SIOS DataKeeper 볼륨 크기 조정 또는 거울. 이 경우 우리는 보호 SQL 서버 리소스를 통해 장애 조치 클러스터링 . 크기를 조정할 SIOS DataKeeper 리소스는 Volume 's'입니다.

• SIOS DataKeeper를 시작하고 크기를 조정하려는 미러로 이동합니다. 이렇게 하는 이유는 비즈니스 요구 사항이나 공간이 기하급수적으로 부족하기 때문입니다. 먼저 미러링 일시 중지 및 잠금 해제를 선택하여 미러링을 중지하거나 작업에 미러가 여러 개 있는 경우 오른쪽에 있는 작업 패널로 이동하여 일시 중지 및 모든 미러 잠금 해제를 선택할 수 있습니다.
• OK라고 합니다. 미러가 일시 중지되면 이제 소스로 이동하여 공간을 확장하고 확장을 선택하고 다음을 선택한 후 완료합니다. 대상으로 전환하고 동일한 작업을 수행합니다. 연장하고 다음으로 끝내십시오. 미러로 돌아가서 계속을 선택하고 미러를 잠급니다. 미러가 미러링 상태로 돌아갔고 어떤 역할도 오프라인으로 전환되지 않았습니다.

도움이 되었는지 알려주세요!

SIOS LifeKeeper에서 SIOS DataKeeper 스토리지를 제거하는 방법

SIOS 수석 제품(Windows) 지원 엔지니어인 Greg Tucker가 이 3분 분량의 비디오에서 올바르게 제거하는 방법을 보여줍니다. SIOS 데이터 키퍼 저장 SIOS LifeKeeper에서.

DataKeeper를 제거하기 전에 클러스터에서 DataKeeper 리소스를 제거하는 것이 좋습니다.

비디오 끝에서 Greg는 다른 질문이나 문제가 있는 경우 SIOS 지원 연락처 정보를 공유합니다.

클라우드 도입 여정 개선

 

어떤 식으로든 2020년과 2021년의 세상을 바꾸는 사건은 우리가 알고 있던 거의 모든 것을 재편성했습니다. 고가용성 많은 회사가 클라우드 채택 여정을 빠르게 추적했기 때문에 예외는 아닙니다. 폐쇄 및 제한에도 불구하고 많은 IT 팀은 온프레미스 데이터 센터를 클라우드로 전환했습니다. 많은 사람들이 '이제 어떻게 합니까?2022년 클라우드 여정을 수정하기 위해 해야 할 5가지 사항은 다음과 같습니다.

1. 클라우드에 고가용성 추가

클라우드로의 전환 과정에서 많은 IT 및 비즈니스 리더는 COVID-19로 인해 폐쇄된 데이터 센터에서 클라우드로 서비스와 애플리케이션을 이동하기 위해 서두르고 있음을 알게 되었습니다. 다른 사람들은 데이터 센터 폐쇄 때문이 아니라 원격 근무의 갑작스러운 증가로 인한 폭발적인 수요의 물결에 대처하기 위해 클라우드로 돌진했습니다. 어떤 사람들에게는 클라우드로의 여정이 너무 빨라서 고가용성이 포함되지 않았습니다. 이제 그들은 애플리케이션이 여전히 클라우드에서 충돌하고 예기치 않은 중단과 계획되지 않은 다운타임이 여전히 AWS의 천적이라는 것을 (힘들게) 발견했습니다. Azure 및 GCP – 이전 데이터 센터에 있었던 것과 동일합니다.

클라우드 여정을 수정하는 첫 번째 단계는 고가용성을 추가하는 것입니다. 이는 기업에 다음과 같은 몇 가지 의미가 있습니다.

1. 고가용성 중복 아키텍처 설계 및 설계
2. 중요한 구성 요소 및 응용 프로그램을 보호할 소프트웨어 및 서비스 선택
3. 관련 프로세스 및 절차, 최소한의 거버넌스 정의 및 문서화
4. 품질 보증, 절차 테스트 및 혼돈 테스트를 위한 프로덕션 사본 배포

2. 재해 복구를 위한 더 높은 가용성을 위해 확장

물론 모든 사람이 어떤 형태의 클라우드를 고려하지 않고 클라우드로 전환한 것은 아닙니다. 고가용성 . 일부 IT 팀은 HA를 온프레미스로 두지 않을 것을 예견했지만 클라우드로 급하게 이동하면서 중요한 모든 서버를 동일한 클라우드 가용 영역으로 옮겼습니다. 완전한 취약성보다 일부 HA 보호 기능이 있는 것이 좋지만 단일 가용 영역(AZ)에만 서버와 애플리케이션을 배포했다면 이제 대기 클러스터 노드에 대해 다중 AZ로 확장하거나 구축해야 할 때입니다. 다른 지역에 세 번째 노드를 배포하여 재해 복구.SIOS는 수십 명의 고객이 다중 AZ 아키텍처를 계획하고 재해 복구 솔루션.

3. 클라우드 여정 팀 구축

하룻밤 사이에 일부 회사와 IT 팀은 완전한 온프레미스에서 Cloud Formation 템플릿, 빠른 시작 가이드, IAM 역할, 내부 로드 밸런서, 오버레이 IP와 씨름하고 VM 크기가 정확히 무엇을 의미하는지 해독하기 위해 노력했습니다.이제 클라우드로의 여정을 지원할 팀을 구성할 때입니다.이것은 여러 가지를 의미합니다: ㅏ. 용량 추가.완전한 리프트 앤 시프트를 수행할 수 없다면 클라우드 및 온프레미스 애플리케이션을 관리하는 동일한 직원이 있을 것입니다.레거시 솔루션은 변덕스럽고 안정적이고 가용성을 유지하기 위해 많은 작업이 필요한 것으로 알려져 있습니다. 앞서 클라우드 여정을 탐색하려면 가용성 요구 사항을 해결하고, 클라우드 아키텍처를 이해하고, 엔터프라이즈 요구 사항에 맞게 향후 과정을 계획할 수 있는 용량이 필요합니다.

비. 훈련을 통한 스킬 강화 .IT 팀에게 클라우드에 대한 교육을 제공하십시오.향후 과정을 관리하고 계획하려면 클라우드 솔루션, 아키텍처, 모범 사례 및 장단점에 대한 추가 교육을 통해 조직 내에서 IT 우수성을 강화할 방법을 찾으십시오.자신있게 훈련된 직원은 가용성 증가로 배당금을 지급할 뿐만 아니라 경제적이고 확장 가능하며 논리적인 방식으로 가용성, 유지 관리 및 성장을 해결함으로써 배당금을 지급할 것입니다.번역: 나머지 클라우드 인프라를 구축할 때 비용 낭비를 방지합니다.

4. 자동화 및 분석을 통합하여 가동 시간 보장

SIOS Technology Corp의 고객 경험 부사장 저는 HA, DR 또는 해당 팀을 희생하지 않고 2021년에 클라우드로 전환한 여러 회사와 협력했습니다. 필요한 가동 시간(99.99%)을 달성하는 것을 진지하게 생각하고 협상할 수 없는 재해 계획이 있다면 엄격한 분석 및 추가 모니터링을 추가해야 할 때입니다. 가용성 솔루션에 재해 또는 계획되지 않은 다운타임 발생 시 복구를 위한 애플리케이션 인식 자동화 및 오케스트레이션이 있는지 확인합니다. 분석 및 자동화를 추가하여 솔루션을 강화하고 클라우드 마이그레이션을 사후 장애 조치 중 하나에서 오류가 발생하기 전에 사전 알림 및 장애 완화에 이르기까지 한 단계 업그레이드하십시오.성능이 저하된 애플리케이션이나 증가하는 대기 시간, 오류 또는 VM 무응답 동작에 대한 알림을 제때 수신하여 비즈니스 피크 시간에 다운타임을 방지한다고 상상해 보십시오. 분석은 원래 가용성 아키텍처에서 벗어날 수 있는 시스템과 애플리케이션을 드러낼 수 있기 때문에 중요합니다.

5. IT 프로세스 및 거버넌스 업데이트

우리가 실패라고 생각하는 많은 것들이 프로세스의 실패에 뿌리를 두고 있습니다. 조직의 프로세스가 최신 상태이고 문서화되어 있으며 적절하게 전달되고 준수되는지 확인하십시오. 이러한 프로세스에는 누가, 무엇을, 언제, 어디서, 어떻게 모두가 고객과 관련된 비즈니스 전략, 목표 및 조직 요구와 연결되는지와 관련된 몇 가지 핵심 최소값이 포함되어야 합니다.

새 클라우드 환경에 대한 소유권 및 승인 프로세스가 문서화되어 있는지 확인하십시오. 인프라를 확보하는 하드웨어 팀에서 클라우드 팀으로 이동한 고객의 역할과 책임이 상충되거나 충돌하거나 해결되지 않아 발생하는 좌절감을 직접 목격했습니다. 마이그레이션을 통한 혼란은 일련의 고충 중 하나이며 명확한 거버넌스 없이 재해를 파헤치는 것은 훨씬 더 크고 비용이 많이 드는 문제입니다.

클라우드로 도약했다면 거기에 머물면서 클라우드를 작동하게 만드는 것이 여정의 다음 부분입니다.클라우드 여정이 갑작스럽거나 불안정한 경우 클라우드 여정을 개선하기 위해 다음 5가지 사항을 고려하고 SIOS 기술이 클라우드에서의 고가용성뿐만 아니라 클라우드에서 실행하기 위한 프로세스를 개선하는 데 도움이 될 수 있음을 알아두십시오.

-Cassius Rhue, VP, 고객 경험 복제 시오스

한 네트워크에서 다른 네트워크로 미러를 이동하는 방법

SIOS 수석 제품(Windows) 지원 엔지니어인 Greg Tucker는 2노드 시스템의 미러 .
또한 그는 다음과 같이 논의합니다.

• 지정된 네트워크에 미러가 있어야 하는 이유는 무엇입니까?
  • 답은 성능을 개선하고 전체 재동기화를 방지하는 것입니다.
• 언제 이 작업을 수행해야 합니까?
  • 답변: 변경 사항을 발견했다면 최대한 빨리
• 다운타임이 필요합니까?
  • 답: “고가용성” 작업이므로 가동 중지 시간이 없습니다.
• 내 IP 주소를 변경할 수 있는 클러스터의 노드는 몇 개입니까?
  • 답: 3노드 이하

튜토리얼이 완료되면 Greg는 추가 질문이나 문의에 대한 모든 SIOS 지원 연락처 정보를 공유합니다.

한 네트워크에서 다른 네트워크로 미러를 이동하는 방법 | 시오스 의 허가를 받아 재생산 시오스

고가용성 또는 고취약성? 고가용성을 위한 체크리스트

모든 규모의 기업에서 IT 시스템에 대한 수요가 계속 증가하고 있다는 것은 비밀이 아닙니다. 그러나 IT 시스템은 운영, 탄력성 및 고가용성인 경우에만 이러한 비즈니스와 고객에게 효과적입니다. 기업이 기업 가용성을 구축하려고 할 때 취약성을 평가하고 평가하기 위한 기준선을 갖추는 것이 인프라, 소프트웨어, 서비스 및 지원을 성공적으로 통합하여 성공을 증가시키는 차이가 될 수 있습니다.

때로는 가장 기본적인 체크리스트가 솔루션의 가용성 또는 취약성 여부를 분류하는 데 도움이 될 수 있습니까?

조직에 지원하기에 적절한 인프라가 있습니까? 고가용성 ?

• 데이터 센터에 건물 시스템을 측정하기 위한 환경 센서가 있습니까?
• 데이터 센터에 24x7x365 작업이 있습니까?
• 데이터 센터에 다양한 소스의 중복 전원 및 네트워크 연결이 포함되어 있습니까?
• 데이터 센터에 여러 계층의 호스트 및 스토리지 서비스가 포함되어 있습니까?
• 고객 경험 부사장으로서 저는 고객이 인프라 내에서 근본적인 근본적인 문제를 해결하지 않고 고가용성 솔루션을 만들려고 시도하는 것을 보았습니다.

그들은 소프트웨어를 배포하지만 네트워크 인프라, 서버 및 데이터 센터 자체 내에서 불안정합니다. 클라우드는 많은 인프라 문제를 해결하지만 모든 클라우드 플랫폼이 동일하게 설계되는 것은 아닙니다. 데이터 센터, 온프레미스 또는 클라우드를 이해해야 합니다.

조직에 디자인, 아키텍처 및 프로세스를 다루는 런북(또는 플레이북)이 있습니까?

• 런북이 잘 문서화되고 공개되며 쉽게 액세스할 수 있습니까?
• Runbook의 일상적인 부분이 충분히 자동화되어 있습니까?
• 누가 엔터프라이즈 Runbook에 액세스할 수 있습니까?
• 현재 유지되고 있습니까?
• Runbook 및 그 안에 포함된 자동화 도구에 대한 버전 제어가 있습니까?

런북 또는 플레이북이 무엇인지 대답했다면 첫 번째 단계는 런북 또는 플레이북을 찾거나 만드는 것입니다. Runbook(또는 플레이북)은 조직이 고가용성 시스템 아키텍처와 관련하여 시스템 및 프로세스를 유지 관리하는 데 도움이 됩니다. 일부 회사는 자동화된 도구를 사용하여 서버를 배포 및 구성하는 스크립트를 생성하고, 다른 회사는 버전 제어 문서를 사용하여 복원력과 성공을 제공하기 위해 모든 것이 함께 작동하는 방법을 설명합니다. 당신의 팀은 새로운 사람들과 기존 팀원들이 사용되는 환경, 프로세스 및 도구를 이해하기 위해 갈 수 있는 장소가 필요합니다.

조직에 고가용성 모범 사례를 유지하기 위한 전담 리소스가 있습니까?

• 귀하의 조직은 이러한 직원과 계약자에게 지원과 교육을 제공합니까?
• 조직에서 이러한 팀에 더 나은 모범 사례를 적용하고 생성할 수 있는 자율성을 부여합니까?

IT 관리자는 "이 시스템을 설정한 것이 아닙니다"라고 말했습니다. 애도는 정직하고 조직에서 자주 관찰되는 현상이었습니다. 인수합병, 비용 절감, 아웃소싱 또는 일반 직원 이직의 결과이든, 고가용성 기업의 핵심 구성 요소는 충분한 인력입니다. 매우 취약한 기업의 핵심은 인력 부족, 교육 부족 또는 지원 부족입니다.

조직에 적절한 변경 관리 제어 기능이 있습니까?

• 정기적인 업데이트 정책과 일정이 있습니까?
• 패치 유지 관리에 대해 정의된 프로세스가 있습니까?
• 패치(취약점, 위협 등)에 대한 검토 프로세스가 있습니까?

변경 관리가 중요합니다. 변경 관리 제어 및 정책은 위험을 줄이고 시스템을 사용할 수 있도록 하는 데 절대적으로 필요합니다. 적절한 제한이 없는 사용자는 안정성을 파괴하는 패키지 또는 업데이트를 추가하거나 몇 시간 동안 조직을 방해하는 변경을 수행할 수 있습니다. 또한 정의된 정책이 없으면 종종 예상(문서화)과 실제(적소에 있는) 사이에 드리프트가 발생합니다. 변경 관리는 또한 대기 클러스터가 기본/소스 시스템과 동일한 패치 및 소프트웨어 수준에 있고 QA(또는 사전 프로덕션)가 프로덕션에서 크게 벗어나지 않도록 하는 데 중요합니다.

조직에 적절한 액세스 제어가 있습니까?

• 서버 관리를 위한 계정 관리 계층이 있습니까?
• 우발적인 다운타임을 방지하기 위한 제어 장치가 있습니까?

우리 서비스 팀은 고객 통화에 참여하여 소프트웨어를 구성 및 업데이트하기 위해 세션에 참여하기 위해 일련의 상승된 명령을 실행할 수 있는 권한이 있는 관리자를 기다리고 기다리고 기다렸습니다. 몇 주 후, 우리 팀은 다른 고객 통화에 합류했고 모두 관리 권한이 있는 여러 사용자가 동일한 클러스터에서 수많은 명령을 실행하는 것을 공포에 떨었습니다. 두 호출의 차이점은 액세스 제어가 중요하다는 것을 놀랍도록 명확하게 지적했습니다. 고가용성 기업은 구성을 손상시키거나 작업을 감소시킬 수 있는 상승된 명령을 사용자가 실행하지 못하도록 적절한 액세스 제어가 마련되어 있는지 확인해야 합니다. 사용자가 자신의 역할, 요구 사항 및 경험에 따라 수행할 수 있는 작업에 제한이 있는지 확인합니다.

회사에 정기적인 테스트 프로세스가 있습니까?

• 귀사는 프로덕션 전에 사전 프로덕션 또는 QA 환경에서 테스트합니까?
• 조직에서 정기적인 백업 및 백업 테스트를 수행합니까?
• 조직에서 지속적인 개선을 위해 재해 복구 시나리오와 혼돈 테스트를 실행하고 있습니까?

테스트에는 시간이 걸리지만 고객의 클라우드 마이그레이션 및 고가용성 배포 , 시간은 항상 잘 보냈습니다. 종종 고가용성과 취약성의 차이는 고객이나 파트너의 테스트 프로세스로 귀결될 수 있습니다. 솔루션이 더욱 복잡해짐에 따라 위험과 취약성을 줄이기 위해 테스트와 검증이 점점 더 중요해지고 있습니다. 모든 것이 설계에서 생산에 이르는 경우 매우 취약한 시스템을 실행하고 있는 것입니다. 그러나 테스트와 체크포인트가 있는 경우 프로덕션에 적용하기 전에 변경 사항을 확인하는 프로세스가 크게 줄어듭니다. 고객 경험 담당 부사장으로서 우리 서비스 팀은 실제 마이그레이션을 완료하기 전에 QA에서 1년 내내 시스템을 배포한 배너 고객과 협력했습니다. 그 해 동안 그들은 정전, 재해, 고객 부하, 가동 중지 시간, 유지 관리, 패치 전략, 백업, 백업에서 복구 및 기타 여러 테스트 제품군을 시뮬레이션했습니다. 결과적으로 성능, 프로세스 준수, 고가용성 및 기업 성공에서 놀라운 결과를 얻었습니다.

고가용성의 모든 잠재적인 취약점을 다룰 수 있는 체크리스트는 없지만 이러한 질문에 답하면 기업이 고가용성인지 아니면 매우 취약한지 이해하기 위한 강력한 토대가 됩니다.

의 허가를 받아 재생산 시오스