SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • 제작품
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • 뉴스 및 이벤트
  • 서버 클러스터 단순화
  • 성공 사례
  • 저희에 게 연락
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

시작을 잘하는 것도 좋지만 가동 시간을 유지하려면 주의가 필요합니다

9월 28, 2021 by Jason Aw Leave a Comment

시작을 잘하는 것도 좋지만 가동 시간을 유지하려면 주의가 필요합니다

 

 

시작을 잘하는 것도 좋지만 가동 시간을 유지하려면 주의가 필요합니다

작가 이사벨라 포레시스(Isabella Poretsis)는 “무엇인가를 시작하는 것은 쉬울 수 있지만, 그것을 끝내는 것이 가장 큰 장애물입니다.”라고 말합니다. 시작 회의를 하는 것이 좋습니다.상쾌하고 흥미진진합니다. 관리자와 리더는 설렘과 낙관으로 그린필드를 바라보고 있습니다.그러나 이 시작의 순간, 성공적인 배치의 샴페인 터지는 순간조차도 시작에 불과합니다. 가동 시간을 유지하려면 지속적인 주의가 필요합니다.

중요한 애플리케이션과 데이터베이스에 대한 고가용성과 99.9999%의 가동 시간은 일시적인 것이 아니라 포도원을 파괴하는 작은 여우를 없애기 위한 끊임없는 노력입니다.위협에 뒤처지지 않고 최신 업데이트를 유지하며 적절하게 훈련되고 준비되는 것은 귀하의 팀이 "휴가를 가질 자격이 없는" 작업입니다.

가동 시간 유지에 주의를 기울이고자 하는 사람들을 위해 다음 5가지 팁을 제공합니다.

1. 환경 모니터링

엔터프라이즈 소프트웨어에서는 여전히 "설정하고 잊어버리십시오"라는 사고방식을 따르는 경우가 거의 없습니다.그랜드 오프닝 샴페인의 코르크 마개를 푼 날부터 지금까지 모든 것이 쇠퇴의 상태로 나아가고 있습니다.서버, 워크로드, 네트워크 트래픽 및 하드웨어(가상 또는 물리적)를 모니터링하지 않으면 가동 시간과 안정성을 잃을 수 있습니다.

2. 유지 보수 수행

20년이 넘는 소프트웨어 개발 및 서비스에서 내가 항상 알아차린 한 가지는 모든 소프트웨어에는 업데이트가 함께 제공된다는 것입니다.적용합니다.백업 수행 및 확인을 포함하여 건전한 유지 관리 정책을 실행하는 것을 잊지 마십시오. 한 기술 작가는 당신이 후회하는 유일한 업데이트는 당신이 하지 못한 업데이트라고 제안했습니다.

3. 지속적으로 배우기

고가용성에 대한 나의 첫 소개는 CE-211 연구실에서 갓 나온 인턴으로 우리 연구실의 서버용 토큰 링의 한쪽 끝을 뽑았을 때였습니다.관리자는 몇 분 안에 내 얼굴에 있었다.귀를 기울이고 나서 그는 나에게 교육을 시켰다.이상적으로는 귀하와 귀하의 팀이 네트워크를 중단하지 않고 학습하기를 원하지만 계속 학습하기를 절대적으로 원합니다.기존 기술, 새로운 릴리스, 새로운 인프라에 대한 유료 과정을 살펴보십시오.프로세스, 환경, 소프트웨어 배포 및 회사 엔터프라이즈와 관련된 과정 및 항목에 대해 공급업체를 확인하십시오.돈이 문제라면 많은 것을 위한 무료 코스도 존재합니다.

4. 학습을 배가하라

지속적인 학습 외에도 학습을 배가할 계획을 세웁니다.SIOS의 고객 경험 부사장으로서 우리는 학습 내용을 공유하는 팀과 공유하지 않는 팀 간의 엄청난 차이를 보았습니다.학습을 공유하는 팀은 다운타임을 손상시키는 지식의 격차를 피합니다.당신이 무언가를 배웠다는 것을 아는 가장 좋은 방법은 그것을 다른 사람에게 가르치는 것입니다. 학습하는 동안 오류로 인한 가동 중지 시간의 위험을 줄이기 위해 팀 구성원과 학습 내용을 공유하고 그 문제에 대해서는 휴가를 제공합니다.

5. 잘 끝낸다. . .다음 시작 전에

모든 프로젝트, 서버 및 소프트웨어에는 끝이 있습니다.잘 끝내세요.올바르게 해제합니다.느슨한 끝을 닫고 잘 된 것과 그렇지 않은 것, 다음에 할 일을 문서화하여 다음 단계, 배포, 소프트웨어 관계 등을 잘 시작하십시오.기존 공급업체를 잘 대우하십시오.나중에 다시 필요할 수 있습니다.새 배포를 진행하기 전에 기존 시스템과 고가용성 솔루션을 이해합니다.이 적절한 결말은 더 나은 출발점에서 더 강한 결과를 향해 다시 시작하는 데 도움이 됩니다.

시스템을 고가용성으로 유지하는 것은 지속적인 프로세스입니다.설정하고 잊어버리면 좋은 캐치프레이즈이지만 가동 시간에는 경계, 지속적인 모니터링, 적절한 유지 관리 및 지속적이 필요하다는 것이 현실입니다.

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

Filed Under: 서버 클러스터 단순화

스플릿 브레인 시나리오 이해 및 피하기

9월 23, 2021 by Jason Aw Leave a Comment

스플릿 브레인 시나리오 이해 및 피하기

 

 

스플릿 브레인 시나리오 이해 및 피하기

분할 뇌. 우리 블로그의 대부분의 독자는 컴퓨팅 맥락에서 이 용어를 들어보았을 것입니다. 그러나 누군가가 두 개의 두뇌를 가지고 있고 둘 다 동등하게 제어할 수 있는 혼돈에 대한 첫 번째 정신적 이미지가 있는 사람들과 동정하지 않을 수 없습니다. 동시에.

장애 조치 클러스터 분할 브레인 시나리오란 무엇입니까?

장애 조치 클러스터 스플릿 브레인 시나리오에서 두 노드는 서로 통신할 수 없으며 대기 서버는 활성 노드가 실패했다고 생각하기 때문에 스스로를 활성 서버로 승격할 수 있습니다. 그 결과 두 노드가 모두 ‘활성’ 상태가 되어 서로가 실패한 것으로 간주됩니다. 결과적으로 두 노드의 데이터가 변경됨에 따라 데이터 무결성과 일관성이 손상됩니다. 이를 스플릿 브레인이라고 합니다.

적절한 조치를 취하지 않으면 SAP HANA 리소스 계층 구조에 대해 두 가지 유형의 분할 브레인 시나리오가 발생할 수 있습니다.

  • HANA 리소스 스플릿 브레인: HANA 리소스는 여러 클러스터 노드에서 활성(ISP)입니다. 이 상황은 일반적으로 클러스터 노드 간의 통신 경로에 영향을 미치는 일시적인 네트워크 중단으로 인해 발생합니다.
  • SAP HANA 시스템 복제 스플릿 브레인: HANA 리소스는 기본 노드에서 활성(ISP)이고 백업 노드에서 대기(OSU)이지만 데이터베이스가 실행되고 두 노드에서 기본 복제 사이트로 등록됩니다. 이 상황은 일반적으로 장애 조치 중에 이전 기본 노드에서 데이터베이스를 중지하지 못하거나 데이터베이스에 대해 자동 시작이 활성화되어 있거나 데이터베이스 관리자가 클러스터링 소프트웨어 환경 외부의 보조 복제 사이트에서 “hdbnsutil -sr_takeover”를 수동으로 실행하는 경우에 발생합니다. .

스플릿 브레인 문제 피하기

각 유형의 분할 브레인 시나리오를 피하거나 해결하기 위한 권장 사항 SIOS 보호 제품군 클러스터링 환경은 아래와 같습니다.

분할 브레인 시나리오에서 다음과 유사한 메시지가 기록되고 문제가 해결될 때까지 quickCheck 간격(기본값 2분)마다 열려 있는 모든 콘솔에 브로드캐스트됩니다.

EMERG:hana:quickCheck:HANA-SPS_HDB00:136363:WARNING: 서버 hana2-1과 
hana2-2 사이에 일시적인 통신 장애가 발생했습니다. 데이터 손실 위험을 최소화하려면 수동 
개입이 필요합니다. 
이 상황을 해결하려면 hana2-1의 HANA-SPS_HDB00 또는 hana2-2의 HANA-SPS_HDB00과 
같은 리소스 계층 중 하나를 사용하지 마십시오. 
리소스 계층 구조가 서비스에서 제외된 서버는 보조 SAP HANA 시스템 복제 사이트가 됩니다.

해결을 위한 권장 사항:

  1. 각 클러스터 노드의 데이터베이스를 조사하여 어떤 인스턴스에 최신 데이터나 관련 데이터가 포함되어 있는지 확인합니다. 이 결정은 데이터에 대해 잘 알고 있는 자격을 갖춘 데이터베이스 관리자가 수행해야 합니다.
  2. 유지해야 하는 데이터가 포함된 노드의 HANA 리소스는 LifeKeeper에서 활성(ISP)으로 유지되며, 보조 복제 사이트로 다시 등록될 노드의 HANA 리소스 계층 구조는 라이프키퍼. 계층을 서비스에서 제외해야 하는 노드의 HANA 리소스 계층에서 각 리프 리소스를 마우스 오른쪽 버튼으로 클릭하고 서비스 중단 …
  3. SAP HANA 리소스 계층 구조가 성공적으로 중단되면 LifeKeeper는 다음 quickCheck 간격(기본값 2분) 동안 대기 노드를 보조 복제 사이트로 다시 등록합니다. 복제가 재개되면 활성 노드에 없는 대기 노드의 모든 데이터는 손실됩니다. 대기 노드가 보조 복제 사이트로 다시 등록되면 SAP HANA 계층 구조가 고가용성 상태로 돌아갑니다.

SAP HANA 시스템 복제 분할 브레인 해결

이 스플릿 브레인 시나리오에서는 다음과 유사한 메시지가 기록되고 모든 열려 있는 콘솔에 빠르게 브로드캐스트됩니다. 문제가 해결될 때까지 간격(기본값 2분)을 확인합니다.

EMERG:hana:quickCheck:HANA-SPS_HDB00:136364:WARNING: SAP HANA 데이터베이스 
HDB00이 실행 중이며 hana2-1 및 hana2-2 모두에서 기본 마스터로 등록되어 있습니다. 
데이터 손실 위험을 최소화하려면 수동 개입이 필요합니다. 이 상황을 해결하려면 해당 서버에서 
'su – spsadm -c “sapcontrol -nr 00 -function Stop”' 명령을 실행하여 
hana2-2에서 데이터베이스 인스턴스 HDB00을 중지하십시오. 중지되면 보조 SAP HANA 
시스템 복제 사이트가 됩니다.

해결을 위한 권장 사항:

  1. 각 클러스터 노드의 데이터베이스를 조사하여 Active 노드에 없는 중요한 데이터가 Standby 노드에 있는지 확인합니다. 스플릿 브레인 상태에서 대기 노드의 데이터베이스에 중요한 데이터가 커밋된 경우 데이터를 수동으로 활성 노드에 복사해야 합니다. 이 결정은 데이터에 대해 잘 알고 있는 자격을 갖춘 데이터베이스 관리자가 수행해야 합니다.
  2. 누락된 데이터가 대기 노드의 데이터베이스에서 활성 노드로 복사되면 LifeKeeper 경고 메시지에 제공된 명령을 실행하여 대기 노드의 데이터베이스를 중지합니다.

    su – adm -c “sapcontrol -nr <Inst#> -function Stop” 여기서 은 HANA 설치를 위한 소문자 SAP 시스템 ID이고 <Inst#>는 HDB 인스턴스의 인스턴스 번호(예: 인스턴스 번호, 예를 들어 HDB00은 00)

  3. 데이터베이스가 성공적으로 중지되면 LifeKeeper는 다음 quickCheck 간격(기본값 2분) 동안 보조 복제 사이트로 대기 노드를 다시 등록합니다. 복제가 재개되면 활성 노드에 없는 대기 노드의 모든 데이터는 손실됩니다. 대기 노드가 보조 복제 사이트로 다시 등록되면 SAP HANA 계층 구조가 고가용성 상태로 돌아갑니다.

일반적인 스플릿 브레인 시나리오를 인식하고 이를 완화하기 위해 이러한 단계를 수행하면 시간을 절약하고 데이터 무결성을 보호할 수 있습니다.

 

 

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

Filed Under: 서버 클러스터 단순화 Tagged With: 리눅스

고가용성 아키텍처 및 모범 사례

9월 16, 2021 by Jason Aw Leave a Comment

고가용성 아키텍처 및 모범 사례

 

 

고가용성 아키텍처 및 모범 사례

고가용성에 대해 거의 알려지지 않은 사실 13가지

1. 하이퍼바이저 HA는 애플리케이션 HA와 동일하지 않습니다.

주요 오해는 하드웨어 또는 하이퍼바이저에 중복성이 있기 때문에 고가용성을 갖는다는 것입니다. 그러나 하드웨어 및 하이퍼바이저 중복성은 다음을 보장하지 않습니다. 고가용성 응용 프로그램을 위해. 또한 오류 발생 시 응용 프로그램의 오케스트레이션이 올바르게 실행된다는 보장도 없습니다.

2. 고가용성에서 더 큰 것이 더 나은 것은 아닙니다.

당신이 파워리프터라면 더 큰 중량이 더 좋고 더 적은 횟수가 더 좋습니다. 또는 포옹에 대해 이야기하는 경우. (포옹은 우리가 다른 도시에서 온 친구를 만났을 때 하던 일, 한동안 보지 못했던 일을 기억합니다.) 그러나 더 크다는 것이 항상 더 좋은 것을 의미하지는 않습니다. 예를 들어, 더 큰 신장 결석은 확실히 더 좋지 않습니다. 고가용성에서 더 크고 더 복잡한 솔루션을 만든다고 해서 항상 고가용성을 높일 수 있는 것은 아닙니다. 가용성이 같거나 더 적음을 의미할 수 있습니다. 또한 가동 중단 시 처리해야 할 이동 부분이 많은 더 크고 복잡한 시스템이 있음을 의미할 수도 있습니다.

3. 모든 것이 실패… 때때로

응용 프로그래밍 언어는 1950년대로 거슬러 올라갑니다. 그리고 언어, 프로세서, IDE 및 코드 품질이 향상되었지만 현실은 “모든 응용 프로그램은 어느 시점에서 실패”합니다. 예외, 버그, 처리되지 않은 종료, 우발적인 종료, 리소스 고갈 등으로 인한 실패가 발생합니다. 능동/능동 또는 능동/수동 애플리케이션 가용성 전략이 여전히 필요합니다.

4. ‘어떻게’보다 ‘왜’에 집중하라

작업 완료 모드로 뛰어드는 우리의 자연스러운 경향은 필수 자산이지만, 이유에 대한 우리의 질문에 대한 답변에 따라 조정되고 안내되어야 합니다. 비즈니스, 애플리케이션, 데이터베이스 및 이해 관계자 요구 사항을 이해하지 않고 환경에 솔루션을 추가하면 다음 중 하나가 발생합니다.

  • 실패
  • 초과 지출
  • 실적 부진
  • 혼돈과 건축
  • 무엇보다도

가용성 구현에만 집중하는 대신 비즈니스 요구 사항을 이해하고 “이유”에 대한 답을 찾는 데 필요한 리소스와 노력을 투자하십시오.

5. 패치되지 않은 문제는 일반적인 후회의 원인입니다.

하거나 하지 않으면 결과가 있습니다. 패치되지 않은 모든 문제의 결과는 후회입니다. 고객 경험 담당 부사장으로서 저는 고객이 알려진 문제를 적시에 해결하지 못해 발생하는 가동 중지 시간을 직접 목격했습니다.

6. 문서화되지 않은 문제로 인해 다운타임도 발생합니다.

장면을 그려보세요. 새 관리자가 네트워크의 서버를 조사하고 있습니다. 사용 보고서는 서버가 활성 상태가 아니며 연결된 클라이언트가 없음을 나타냅니다. 서버를 인식하지 못하고 “태그”, 문서 또는 기타 식별자를 찾지 못한 새 관리자는 서버를 종료해야 한다고 생각합니다. 불행히도 문서화되지 않고 통신되지 않은 인스턴스는 실제로 대기 서버로, 기본 서버가 예기치 않게 충돌할 때 제거로 인해 가동 중지 시간이 발생합니다. 이것은 허구의 이야기가 아닙니다. 이것은 서버를 유휴 QA 시스템으로 잘못 식별하고 패치 작업 전에 종료한 새 관리자의 실화입니다.

7. 안일함도 적이다

온프레미스나 클라우드 또는 그 사이의 어느 곳에서든 가용성이 “설정하고 잊어버릴 수 있는” 것이라면 모두가 좋아할 것입니다. 그러나 인생에서 “설정하고 잊어버리십시오”만큼 간단한 것은 거의 없습니다. 미래 가용성의 가장 큰 적 중 하나는 지금 고가용성을 통한 성공입니다. 재해가 거의 없고 팀이 지속적인 안정성을 실현했다고 확신할 때 안주가 개입할 수 있습니다. 성공은 우리로 하여금 아무 것도 변하지 않을 것이라고 생각하게 만들고 고가용성에 대한 안일함은 고가용성의 적입니다. 기업 주변과 기업 내부의 상황이 변화하고 있습니다. 클라우드가 변하고 비즈니스 요구가 변하고 애플리케이션과 운영 체제도 변하고 있습니다.

8. 변화는 어렵다

변화는 어렵다. 취침 전에 케이크의 두 번째 조각을 포기하려고 애쓰는 단 것을 좋아하는 사람에게 물어보십시오. 고가용성에서도 유사한 저항이 발생합니다. 팀은 재난을 경험한 팀이라도 좋은 변화라도 변화를 꺼리는 경우가 많습니다. 그들에게는 비전, 이유에 대한 이해, 지원이 필요합니다. 솔루션을 갖춘 다른 팀은 불안정을 초래하거나 새로운 위험에 노출될까 두려워 고가용성을 개선하기를 꺼립니다.

9. 모든 변화가 좋은 변화는 아니다

변화가 좋을 때 변화가 좋다. 고가용성 솔루션 및 아키텍처에 대한 변경을 고려할 때 목표, 요구 사항 및 가용성 증가 범위 내에서 변경 사항을 분석하는 것이 중요합니다. 안정성을 높이고, 중요한 구성 요소에 대한 보호를 추가하고, 대안을 제거하고, 서비스 가용성을 최적화하고, 철저하게 테스트하는 변경은 좋은 변경입니다.

10. 더 싼 것이 항상 좋은 것은 아니다

저렴하다고 항상 좋은 것은 아닙니다. 저렴한 솔루션은 일반적으로 가격표가 더 낮지만 이상적이지 않은 여러 제한 사항이 있을 수도 있습니다. 더 낮은 가격표가 있는 경우 애플리케이션 인식 부족, 제한된 오케스트레이션, 숨겨진 복잡성, 수동 복구 및 장애 조치 , 사용자 검증이 없는 것으로 제한됩니다. 저렴한 솔루션에는 고객 지원이 포함되지 않을 수도 있습니다. 더 저렴한 솔루션에 지원이 포함되는지 또는 지원이 추가 및 상당한 애드온 비용인지 이해해야 합니다.

컴퓨팅, 디스크 또는 스토리지가 감소된 저렴한 배포에도 동일하게 적용됩니다. 가격표와 월별 비용이 더 낮을 수 있지만 솔루션이 이상적인 용량보다 적게 작동할 수도 있습니다.

11. 시끄러운 것은 효과적이지 않다

늑대 우는 소년의 이야기를 들어본 적이 있습니다. 경고 폭풍을 생성하는 애플리케이션 모니터링 솔루션은 나중에 무시되는 솔루션입니다. 경고를 제공하는 솔루션을 갖는 것은 좋지만 해당 솔루션이 오류 또는 초과로 중요한 경고를 트리거하면 효과가 없습니다.

12. 고가용성은 단순한 제품이나 하드웨어 솔루션이 아닌 문화이자 사고방식입니다.

소프트웨어, 하드웨어, 프로세스, 솔루션 및 서비스는 모두 고가용성의 일부입니다. 그러나 IT 기능 및 사업부 전반에 걸친 동의 없이는 가치, 비즈니스 안정성, 고객 만족도 향상 및 위험 감소에 대한 논의 대신 좌절감과 계속해서 예산 논의의 원천이 될 것입니다.

13. 아직 늦지 않았다

희망은 고가용성을 위한 전략이 아니며 치명적인 재해나 애플리케이션 오류가 발생하지 않기를 바라는 것도 전략일 필요가 없습니다. 고가용성 엔터프라이즈 아키텍처를 설계하고 설계하는 것은 마지막 재해 이후 몇 주 또는 몇 달이 지난 경우에도 가능합니다.

SIOS에 문의 에 대해 자세히 알아보기 고가용성 솔루션 당신의 신청을 위해.

– Cassius Rhue, VP, 고객 경험 재현 시오스

 

 

Filed Under: 서버 클러스터 단순화

클라우드 마이그레이션을 복잡하게 만드는 12가지 질문

9월 10, 2021 by Jason Aw Leave a Comment

클라우드 마이그레이션을 복잡하게 만드는 12가지 질문

클라우드 마이그레이션을 복잡하게 만드는 12가지 질문

클라우드 마이그레이션 권장사항

“클라우드가 점점 더 복잡해지고 있습니다.”는 클라우드 컴퓨팅 및 클라우드 마이그레이션의 붐으로 인한 변화와 기회에 대해 자세히 설명하는 1시간 길이의 웨비나의 첫 번째 진술이었습니다.발표자는 기존 IT가 현재 직면하고 있는 클라우드 관련 사항에 대한 개요를 계속했습니다. AWS , 하늘빛 , GCP 또는 다른 공급자.

클라우드로의 전통적인 전환 과정에서 복잡하게 드러난 9가지 영역이 있습니다.

  • 정의
  • 가격
  • 네트워킹
  • 보안
  • 사용자, 역할 및 프로필
  • 애플리케이션 및 라이선스
  • 서비스 및 지원
  • 유효성
  • 백업

SIOS Technology Corp의 고객 경험 부사장으로서 저는 다음 영역이 클라우드로의 전환에 어떤 영향을 미칠 수 있는지 확인했습니다. 이러한 복잡성을 완화하기 위해 소비자는 관리형 서비스 제공업체, 클라우드 솔루션 설계자, 계약자 및 컨설턴트, 수많은 관련 서비스, 가이드, 블로그 게시물 및 관련 기사를 찾고 있습니다. 외부 또는 아웃소싱 리소스로 전환하는 과정에서 클라우드의 복잡성이 완전히 제거되지 않는 경우가 많습니다.대신, 지원하거나 클라우드로 전환하기 위해 고용한 회사와 팀은 여전히 장애물, 과속 방지턱, 딸꾹질 및 차질에 직면합니다.

대부분의 경우 클라우드로 마이그레이션할 때 이러한 복잡성과 속도 저하가 12가지 답이 없는 질문에서 비롯됩니다.

  1. 클라우드로 전환하는 우리의 목표는 무엇입니까?
  2. 현재 온프레미스 아키텍처는 무엇입니까?문서, 목록, 순서도 또는 요리책이 있습니까?
  3. 대상 클라우드 공급자 플랫폼에서 모든 애플리케이션, 데이터베이스, 가용성 및 관련 공급업체가 지원됩니까?
  4. 현재 온프레미스 위험 및 제한 사항은 무엇입니까?보호되지 않는 애플리케이션은 무엇이며, 온프레미스에서 직면하는 가장 일반적인 문제는 무엇입니까?
  5. 클라우드 아키텍처 및 설계를 담당하는 사람은 누구입니까?이 아키텍처와 디자인은 현재 정의와 클라우드 제공자의 정의를 어떻게 설명합니까?
  6. 주요 이해 관계자는 누구이며 비즈니스 프로젝트의 이정표, 비즈니스 동인 및 기한은 무엇입니까?
  7. 프로젝트 계획 및 이정표를 공급업체와 공유했습니까?
  8. 현재 프로세스, 거버넌스 및 비즈니스 요구 사항은 무엇입니까?
  9. 마이그레이션 예산은 얼마이며 여기에는 인력 보강, 교육 및 서비스가 포함됩니까? 지속적인 유지 관리, 라이선스 및 운영 비용에 대해 어떻게 예상하십니까?
  10. 팀의 기존 기술과 책임은 무엇입니까?
  11. 누가 거버넌스, 프로세스, 새로운 클라우드 모델, 다양한 기존 역할과 책임을 업데이트할 책임이 있습니까?
  12. IaaS에서 SaaS 모델로 이동할 애플리케이션, 서비스 또는 기능은 무엇입니까?

클라우드에 대한 목표 파악

따라서 이 12가지 질문에 답하면 클라우드 마이그레이션을 개선할 수 있습니다. 질문에서 알 수 있듯이 클라우드에 대한 목표를 이해하는 것이 첫 번째이자 가장 중요한 단계입니다.”AWS, Azure 또는 Google과 같은 클라우드 서비스 공급자가 특정 애플리케이션에 필요한 서버, 스토리지 및 통신 리소스를 제공할 수 있다”는 것은 거의 보편적으로 받아들여지고 있지만, 많은 고객에게 이것은 “컴퓨터가 필요하지 않습니다. 하드웨어 및 해당 하드웨어를 관리하는 인력.” 이러한 사실 때문에 고객은 여전히 고려해야 할 추가 클라우드 기회와 격차를 고려하지 않고 장비 또는 데이터 센터 통합 또는 축소에 집중하는 경우가 많습니다. 예를 들어, 클라우드 하다 하드웨어 관리를 제거하지만 “ 하지 않습니다 모니터링 및 복구를 위해 애플리케이션과 해당 종속성이 필요로 하는 모든 요구 사항을 제거하십시오. IaaS 모델.목표를 아는 것은 클라우드 여정을 계획하는 데 큰 도움이 됩니다.

현재 온프레미스 아키텍처 파악

클라우드(또는 모든 새로운 플랫폼)로의 적절한 마이그레이션에 필요한 두 번째 중요한 질문 범주는 현재 온프레미스 아키텍처를 이해하는 것입니다. 이 단계는 가용성이 필요한 중요한 애플리케이션을 식별하는 데 도움이 될 뿐만 아니라 기본 종속성과 클라우드의 스토리지, 네트워킹 및 컴퓨팅 변경 사항을 기반으로 해당 애플리케이션, 데이터베이스 및 백업 솔루션에 필요한 모든 변경 사항을 식별하는 데 도움이 됩니다.이 질문에 답하는 것은 클라우드에 대한 애플리케이션 및 솔루션의 준비 상태를 평가하고 현재 위험을 수량화하는 핵심 단계이기도 합니다.

이러한 질문을 통해 큰 이점을 얻을 세 번째 영역은 현재 제한 사항을 논의하고 수량화할 때 발생합니다.종종 우리는 이 발견 단계에서 클라우드에 존재하지 않는 현재 솔루션의 한계에 대한 문을 여는 것을 봅니다.예를 들어, 최근 우리 서비스 팀은 SQL 데이터베이스 클러스터의 성능 문제로 영향을 받는 고객과 협력했습니다.마이그레이션을 지원하는 SIOS 전문가는 솔루션과 아키텍처, VM 크기 결정에 대해 문의했습니다. 잠시 후 더 큰 애플리케이션 크기의 인스턴스가 배포되어 고객이 컴퓨팅, 메모리 및 스토리지에 대한 온프레미스 제한으로 인해 수용한 제한 사항을 수정했습니다.마찬가지로 우리는 스토리지에 민감한 고객과 협력했습니다.그들은 디스크 용량 제약으로 인해 더 작은 디스크와 빈번한 크기 조정 정책으로 응용 프로그램을 실행했습니다. 스토리지 비용을 고려해야 하지만 최소한의 마진으로 운영하는 것은 과거의 한계가 될 수 있습니다.

비즈니스 및 거버넌스 변경 이해

마지막 질문 그룹은 팀에서 더 이상 클라우드에 적용되지 않을 수 있으므로 업데이트하거나 교체해야 하는 일정, 비즈니스 영향, 마감일 및 거버넌스 변경 사항을 이해하는 데 도움이 됩니다. 클라우드로의 마이그레이션은 순조로운 전환과 여정이 될 수 있습니다.그러나 여행 중 어디에 있는지, 언제 여행을 완료해야 하는지 평가하지 못하면 악몽에 빠질 수 있습니다. 타이밍을 이해하는 것은 중요하며 이해 관계자, 애플리케이션 공급업체, 비즈니스 이정표 및 비즈니스 시즌을 고려하여 크게 도움을 받을 수 있습니다.이기적으로 SIOS Technology Corp.은 서비스 제공자로서 놀라움을 최소화하기 때문에 고객이 이정표를 이해하기를 바랍니다. 그러나 우리는 또한 고객이 부서와 이해 관계자 간의 불일치를 자주 발견하므로 이러한 질문에 답할 것을 권장합니다. DBA는 컷오버가 해당 월의 마지막 주말에 발생할 것으로 생각하지만 재무부는 같은 달의 마지막 주말에 장부를 마감할 계획입니다. 또는 IT 팀은 전환이 월요일에 발생할 수 있다고 생각하지만 애플리케이션 팀은 수요일까지 사용할 수 없으며 아마도 가장 중요한 것은 법무팀이 전환을 가져오는 데 필요한 새로운 NDA, 계약, 라이선스 및 거버넌스 변경 목록을 검토하지 않았다는 것입니다. 모두 함께.

고객이 안전하고 공감하는 마음으로 질문을 처리할 때 종종 등장하는 것은 조각, 소유권, 프로세스 및 의사 결정권자의 퍼즐입니다. 이 퍼즐은 클라우드 제공업체 상자 상단과 예산, 인력 배치, 교육에 대한 정직한 대화를 사용하여 다시 결합해야 합니다. , 및 서비스.최종 결과는 완벽한 마이그레이션이 아닐 수 있지만 확실히 성공적인 마이그레이션이 될 것입니다.

클라우드 마이그레이션 전략 및 고가용성 구현에 대한 도움이 필요하면 SIOS Technology Corp.에 문의하십시오. – Cassius Rhue, VP, Customer Experience common에 대해 자세히 알아보기 클라우드 마이그레이션 과제 .

에 대한 몇 가지 오해에 대해 읽어보십시오. 클라우드의 가용성.

에서 재생산 시오스

Filed Under: 서버 클러스터 단순화

효과적인 IT 시스템 이중화를 위한 3단계

9월 5, 2021 by Jason Aw Leave a Comment

효과적인 IT 시스템 이중화를 위한 3단계

효과적인 IT 시스템 이중화를 위한 3단계

일부 산업에서 중복 작업은 회사 자원의 낭비가 될 수 있으며 의도하지 않은 인적 오류와 시간 손실을 초래할 수 있습니다. 그러나 시스템 및 데이터를 관리하는 IT 세계에서 “중복”이라고 하는 복제 프로세스는 조직의 지속적인 성공에 매우 중요합니다.

1. 이중화 도구로 장치와 소프트웨어를 모두 보호하십시오

이중화를 제공하는 IT 도구는 시스템 및 소프트웨어 자산을 손실 또는 손상으로부터 보호합니다. 또한 비즈니스 중단을 복구하기 위해 시기적절한 복구를 제공해야 합니다.

IT 시스템의 중복성은 하드웨어, VM 또는 클라우드에서 시스템 구성 요소를 복제할 수 있는 능력을 의미합니다. 사용자 수준에서 간단한 예는 사용자의 PC 시스템을 복사하여 사용자의 PC에 오류가 발생할 경우를 대비하여 예비로 다른 PC에 저장하는 것입니다.

이 동일한 개념은 서버, 저장 장치 및 네트워킹 장비를 포함한 다른 모든 컴퓨터 구성 요소에 적용될 수 있습니다. 예를 들어, “미러링”은 동일한 데이터를 여러 디스크에 기록하여 해당 디스크를 중복으로 만드는 메커니즘입니다.

이중화를 사용하면 가능한 한 빨리 예비 장치로 전환하여 장치 오류를 복구할 수 있습니다. 기업은 IT 시스템에 크게 의존하며 시스템 장애로 인한 서비스 중단은 운영에 상당한 다운타임을 유발할 수 있습니다. 결과적으로 IT 시스템이 장애에 대한 복원력을 유지하고 비즈니스 중단 위험을 줄이기 위해서는 이중화가 필수적입니다. 조직의 규모와 지리적 위치에 따라 어렵고 시간이 많이 걸리고 비용이 많이 들 수 있습니다.

2. 모든 데이터를 최신 상태로 유지하고 클러스터링과 동기화

동일한 사양과 환경(운영 체제 및 소프트웨어)을 가진 중복 장치가 있다고 해서 장애가 발생했을 때 사용자 파일과 이메일, 미션 크리티컬 애플리케이션 데이터의 손실을 자동으로 보호하지는 않습니다. 이는 개별 사용자의 PC뿐만 아니라 여러 서버와 저장 장치에 걸쳐 있는 대규모 기업에서도 마찬가지입니다. 데이터 저장 장치에 오류가 발생하면 최신 데이터에 액세스하지 못한 상태에서 비즈니스 운영이 크게 지연될 수 있습니다. 다음과 같은 대규모 애플리케이션의 경우 SQL 서버 , 신탁 , 또는 수액 , 복구 시간이 상당할 수 있습니다.

불행히도 많은 기업은 단순히 데이터를 백업함으로써 위험을 줄일 수 있다고 생각합니다. 그러나 프로덕션 장치가 갑자기 고장날 때까지 대부분의 사람들은 백업 복사본에서 대기 장치로 데이터를 실제로 복원하는 것이 얼마나 어려운지 깨닫지 못합니다.

이와는 대조적으로, 이미 장애가 발생한 생산 장치에 있던 것과 동일한 데이터를 사용할 수 있는 능력이 있는 대기 장치의 경우 대기 장치를 시작하고 대기 장치로 전환하기만 하면 됩니다. 복구 작업이 훨씬 쉬워집니다. 이것은 고가용성(HA) 클러스터 시스템에서 가능합니다.

클러스터링 예상치 못한 시스템 오류를 보상하기 위해 중복성을 생성하여 소프트웨어 및 하드웨어 시스템의 안정성과 성능을 개선하는 데 도움이 됩니다. HA 클러스터 시스템은 활성 및 대기 시스템의 이중화 서버와 두 서버가 모두 액세스할 수 있는 외부 저장소(예: 공유 디스크)로 구성됩니다. 만일의 경우 운영 서버에 장애가 발생할 경우 대기 서버로 전환하여 대기 서버와 최신 데이터가 저장된 외부 저장소를 결합하여 서비스를 계속할 수 있습니다.

그건 그렇고, “로 동일한 기능을 얻을 수 있습니다. 복제 “, 서버 내부의 디스크간 데이터를 실시간으로 동기화합니다. 복제는 값비싼 외부 저장소를 설치할 필요가 없고 두 인스턴스 모두에서 최신 데이터를 유지하기 때문에 재해 복구에 대한 훌륭한 수단이기도 합니다. 보조 인스턴스의 위치에 따라 데이터는 동기식 또는 비동기식으로 복제됩니다. 데이터 복제 방식은 RTO(복구 시간 목표) 및 RPO(복구 시점 목표)에 영향을 미칩니다.

3. 장애 조치 자동화

HA 클러스터 시스템을 사용하든 복제를 사용하든 가장 좋은 방법은 장애가 발생할 때 서버를 수동으로 전환하지 않는 것입니다. 대신 장애 조치(failover)라는 프로세스에서 지연 없이 수행되도록 프로세스를 자동화합니다. HA 클러스터 시스템 / 복제의 자동 장애 조치를 구성하면 다운타임을 최대한 최소화하고 인적 오류를 줄입니다.

SIOS SAN 기반 및 SANless 클러스터링 솔루션은 다음을 제공합니다. 고가용성 그리고 재해 복구 물리적, 가상, 클라우드 또는 하이브리드 클라우드 환경의 미션 크리티컬 애플리케이션용. 자세한 내용은 다음을 참조하십시오. 윈도우와 리눅스 고가용성 제품 .

에서 재생산 시오스

Filed Under: 서버 클러스터 단순화

  • « Previous Page
  • 1
  • …
  • 59
  • 60
  • 61
  • 62
  • 63
  • …
  • 112
  • Next Page »

최근 게시물

  • 고가용성(HA)이란 무엇인가요?
  • 금요일 밤의 시스템 충돌에서 살아남기: 초라한 베어메탈에서 완벽한 데이터 복제까지
  • Grounded: 암스테르담에서 열린 Percona Live에 참석하지 못한 것이 제게 HA에 대해 가르쳐준 것
  • SIOS LifeKeeper와 Red Hat 고가용성 추가 기능 비교:
  • 애플리케이션 복원력 현황: 2026 SIOS 고가용성 설문조사

가장 인기있는 게시물

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

Copyright © 2026 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in