SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

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

고 가용성 서버 솔루션을 구축하는 방법은 무엇입니까?

3월 16, 2021 by Jason Aw Leave a Comment

고 가용성 서버 솔루션을 구축하는 방법은 무엇입니까?

고 가용성 서버 솔루션을 구축하는 방법은 무엇입니까?

고 가용성 솔루션의 핵심 구성 요소는 클라이언트 트래픽을 리디렉션하는 방법을 파악하는 것입니다. 거의 모든 사용자 기반 애플리케이션은 서버에 연결해야합니다. 클라이언트 트래픽을 리디렉션하면 사용자는 응용 프로그램이나 데이터베이스가 실제로 어디에 있는지 알 필요없이 연결할 수 있습니다.

대부분의 솔루션은 네트워크 기반 IP 리디렉션 또는 네트워크 기반 DNS 리디렉션을 권장합니다. 작동합니다. 그러나 경험상 고 가용성 서버를위한 최상의 솔루션은 한 서버에서 다른 서버로 전환 할 수있는 가상 IP 주소를 사용하는 것입니다. 서버는 현재 한 서버에서 호스팅되고 다른 날에는 다른 서버로 전환되는 가상 IP 주소의 연결을 수신합니다.

한 단계 더 나아 가기 위해 장애 조치를 자동화 할 수 있습니다. 여기에서 오류가 감지되면 시스템이 결정을 내리고 애플리케이션을 전환합니다. 이 단계는 고 가용성 솔루션을 구축하는 데 중요합니다.

구매 및 고 가용성 솔루션 구축의 이점

이것은 스크립트와 로직을 사용하여 한 서버에서 다른 서버로의 프로세스 상태와 가상 IP 주소를 확인하는 것을 구현할 수 있습니다. 그러나 구매 대 고 가용성 솔루션 구축에서 우리가 직면하는 과제 중 하나는 구축에 실제로 얼마나 많은 시간을 소비해야 하는가입니다. 여기에는 스크립트 코딩, cloudwatch API 또는 람다 함수와 같은 API 개발 시간이 포함됩니다. 테스트와 유지 보수를 잊지 말자.

제가 어렸을 때 저는 그 코드를 작성하고 싶었습니다. 하지만 Fortune 100 대 기업에서 일하고 고위 관리자에게 소리를 지르고 오전 3시에 스크립트 중 하나가 작동하지 않았을 때 느낌이 다릅니다. 이 문제는 내가 1 년 전에 작성한 코드에 대한 문제를 발견했을 때 더욱 악화되었습니다. 관리자들은 고 가용성 솔루션이 100 % 작동하기를 원했습니다. 작동하지 않으면 누군가에게 전화를 걸어 소리를지를 시간입니다.

SIOS는 고 가용성을 자동화합니다

장기적으로 솔루션을 구입하고 설정에 맞게 조정하는 데 약간의 시간을 투자하는 것이 더 저렴하지 않습니까? 애플리케이션이나 데이터베이스에 관계없이 SIOS 고 가용성 (HA) 솔루션이 여기에서 제공됩니다. SIOS에는 한 서버에서 다른 서버로 프로세스 스택을 전환하는 코드가 있습니다. 이를 통해 사용자와 관리자는 장애 조치 오케스트레이션과 고 가용성을 자동화하여 안심할 수 있습니다.

내가 SIOS HA 우산에 대해 좋아하는 두 가지가 있습니다. 하나는 IP 주소가 서버에 추가되고 애플리케이션이 연결을 수신하기 위해 다시 시작되는 가상 IP에 대한 코드입니다. 두 번째는 SIOS가 제공하는 애플리케이션에 구애받지 않는 API 세트를 사용하여 활성화됩니다. 이를 통해 누구나 플러그인을 사용하여 모든 애플리케이션을 보호 할 수 있습니다. 환경에 맞는 고 가용성 솔루션에 대해 자세히 알아 보려면 지금 SIOS에 문의하십시오.

– Edmond Melkomian, PMP, MCSD, 컨설턴트, SIOS technology, Inc.

SIOS에서 재현

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

IT 재해 복구 슬픔의 단계

3월 8, 2021 by Jason Aw Leave a Comment

IT 재해 복구 슬픔의 단계

IT 재해 복구 슬픔의 단계

올바른 엔터프라이즈 가용성 아키텍처를 구현하지 않은 경우 재해 복구에 대한 슬픔이 갑자기 나타날 수 있습니다. IT 분야의 친구 Dave를 만나 재해 슬픔의 5 단계를 안내합니다.

1 단계 : 거부

IT 분야의 Dave :“오 오.그 경고는 무엇입니까?약간의 애플리케이션 충돌 일 뿐이죠?별거 아니야.곧 작업을 시작하고 실행할 수 있습니다.”

엔터프라이즈 가용성의 땅에는 약간의 애플리케이션 충돌이나 큰 문제가 없습니다.회사는 실제 돈으로 SLA를 사용합니다.선택적인 현실은 아마도 고객과 이해 관계자의 관점과 같지 않을 것입니다.

2 단계 : 분노

IT 분야의 Dave :“농담하니?무엇보다도 …[censored] … 때로는 오늘 애플리케이션이 시작되지 않습니다.어.이건 싫어요 [censored]..[censored]. 응용 프로그램.이 새로운 경고는 무엇입니까?이제 데이터 센터가 다운되었습니다!”

빠른 속도와 높은 위험 환경에서 정말, 정말 빠르게 지저분 해집니다. 확인되지 않은 경고 및 실패가 발생하면 압력, 좌절 및 분노와 함께 문제가 빠르게 증가 할 수 있습니다.

상태 3 : 교섭

IT 분야의 Dave :“응용 프로그램 분야의 Ard, 저는 IT 분야의 Dave입니다.App1 환경에 대한 백업이 있습니까? . . . 확실한가요?다시 확인해 주 시겠어요?두 번 확인했지만 한 번 더 확인하실 수 있습니다.화요일에 타코에 음료를 살게요!”

IT 분야의 Dave :“Hey Donna DBA, 저는 IT 분야의 Dave입니다. Art in Applications는 당신이 나를 도울 수 있다고 말했습니다.우연히 해당 재무 데이터베이스 또는 재고 관리 시스템에 대한 데이터베이스 복제를 설정 했습니까? . . . 확실합니까?음, 우리가 umh에서 복구 할 방법이 있는지 기억하십니까? . . 데이터 센터 충돌?”

내 딸이 곤경에 처하면 흥정이 그녀의 첫 번째 행선지입니다.좋아, 두 번째.첫 번째는 사라지는 것이지만 당신은 너무 똑똑해서 불길을 피할 수 없습니다.그러나 IT 분야의 Dave 만 협상과 구걸이 고 가용성 및 재해 복구를 위해 잘 정의 된 전략을 대체 할 수 없다는 사실을 깨닫는 유일한 사람은 아닙니다.“80 %의 사람들이 신경 쓰지 않고 20 %가 당신을 기쁘게 생각합니다 (Les Brown에서 패러 프레이징)”때문에 협상을 건너 뛰고 재난에 대해 구걸합니다.

4 단계 : 슬픔

IT 분야의 Dave :“이건 정말 대단합니다.애플리케이션 서버가 고장 났고 데이터 센터가 다운되었으며 백업을 찾을 수 있고로드 할 수 있다면 복원하는 데 몇 시간이 걸립니다.여기서 벗어날 방법이 없습니다. 업데이트 된 이력서를 어디에 넣었습니까?”

물론 백업이 있고 유효성을 검사했습니다.그러나 이러한 백업으로 돌아 가면 RTO 및 RPO에 미치는 영향이 있습니다.이번에는 흡수 할 수 있습니까?물론 데이터 센터가 복구 된 후입니다.

5 단계 : 수락

IT 분야의 Dave :“2 시간이 지났습니다.나는 우리가 이렇게 많은 경영진이 있다는 것을 몰랐습니다.이 후로 2 주년을 맞이할 수 없습니다.글쎄요, 내일 사무실 청소를 할 것 같아요.나는 이것을 통해 그것을 만들 수 없습니다!”

실패가 발생합니다.데이터 센터가 다운됩니다.응용 프로그램이 실패합니다.데이터 센터 손실, 서버 장애 또는 애플리케이션 충돌 가능성을 부인할 수 없습니다.이러한 유형의 수락은 정상이며 가용성 향상의 일부입니다.가용성 전략을 구현하지 못했기 때문에 직장을 잃거나 더 나빠질 수 있다는 사실을 받아들이는 것은 SIOS Technology Corp.의 전문가가 피하고 싶은 것입니다.

IT 분야에서 Dave처럼되지 마십시오.모니터링, 복구 및 시스템 장애 조치 자동화를위한 최상의 솔루션과 결합 된 최상의 하이브리드, 온 프레미스 또는 클라우드를 포함하는 엔터프라이즈 가용성 아키텍처를 설계하고 구현하여 재해 슬픔 단계, 재해 복구 및 다운 타임 시간을 피하십시오. .

– Cassius Rhue, VP 고객 경험

SIOS에서 재현

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

고 가용성이 왜 그렇게 복잡해야합니까?

3월 1, 2021 by Jason Aw Leave a Comment

고 가용성이 왜 그렇게 복잡해야합니까?

고 가용성 사랑이 왜 그렇게 복잡해야하나요?

홀 마크 영화 시즌, 크리스마스 시즌, 홀 마크 크리스마스 영화 시즌 … (너무 가혹하게 판단하지 마세요. 저는 6 명의 젊은 여성의 아버지이고, 절망적 인 로맨틱하고, 좋은 것을 즐기는 멋진 배우자와 결혼했습니다. 휴일 웃음과 해피 엔딩). 홀 마크 영화 시즌에 계신다면“사랑은 왜 그렇게 복잡한가요?”라는 말을들을 가능성이 높다는 것을 알고 계실 것입니다. 상심 한 청년이 새로운 사랑에 대한 관심을 가지기 직전에, 예전의 불꽃이 파티에 들어 오듯 밤새도록 팔에 안고 춤을 출 준비가되어있다.홀 마크 연말 연애에 관심이 없다면 궁금해하는 것이 사랑이 아닐 수도 있습니다.다음과 같이 알고 싶을 것입니다.“고 가용성이 왜 그렇게 복잡해야합니까?

고 가용성이 그토록 복잡한 10 가지 이유 :

  1. 혁신의 속도

    클라우드 컴퓨팅, 엣지 컴퓨팅, 하이퍼 컨 버지 드, 멀티 클라우드, 컨테이너 및 머신 러닝은 빠른 속도로 엔터프라이즈 가용성 환경을 변화시키고 있습니다.보수적 인 추정치에 따르면 AWS는 현재 175 개 이상의 서비스를 보유하고 있으며 "전 세계 190 개 국가에서 수십만 개의 비즈니스를 지원하는 클라우드에서 매우 안정적이고 확장 가능한 저비용 인프라 플랫폼을 제공합니다." 인프라 및 애플리케이션 인식과 함께 이러한 모든 환경에서 일관된 관리를 허용하는 HA 솔루션을 선택하는 것은 복잡성을 줄이는 중요한 방법입니다.

  2. 재난의 무작위성

    누군가는“솔루션을 재난으로부터 보호하면 우주가 더 나은 재난을 구축 할 것입니다.”라고 말한 적이 있습니다. 우리는 기술 영역뿐만 아니라 재난의 세계에서도 혁신을보고 있습니다. 자원 고갈, 냉각 시스템 재해, 자연 재해, 전력망 장애 및 다수의 신규 및 무작위 재해로 인해 기업 전체를 단열하기가 더 어려워지는 경우가 많습니다. 작년의 솔루션은 올해의 전례없는 중단을 처리하기 위해 업데이트가 필요할 것입니다. 수년 동안 고 가용성에 중점을 두어 온 공급 업체와 협력하는 것이 중요합니다. 이러한 공급 업체는 임의의 재난에 대한 솔루션을 직접 찾은 경험이 있습니다.

  3. 애플리케이션 복잡성

    기술이 가상화 및 클라우드 컴퓨팅 영역으로 이동함에 따라 애플리케이션은 제품군을 따르고 있습니다. 이러한 애플리케이션 공급 업체가 클라우드를 활용하기위한 새로운 옵션을 추가함에 따라 복잡성도 추가되고 있습니다.애플리케이션은 AWS, Azure, GCP 또는 기타 환경에서 더 높은 가용성과 클러스터링을 위해 설계된 솔루션으로 보호되어야합니다.애플리케이션을 더 잘 인식하고 모범 사례에 대한 이해를 제공하고 애플리케이션이 어떻게 설계되었는지를 고려하여 설계된 가용성 솔루션을 제공하고 클라우드에서 애플리케이션의 오케스트레이션을 최적화 할 수있는 공급 업체를 찾으십시오.

  4. 위협의 발전

    기업에 대한 위협은 가용성에도 영향을 미칩니다. 시스템은 항상 침입자, 해커, 심지어 자해 자의 공격을 처리해야했습니다.이러한 공격은 더욱 정교 해졌으며 피해를 방지하기위한 솔루션과 방법은 종종 조직 내에 배포 된 레이아웃, 아키텍처 및 소프트웨어에 영향을 미칩니다. 이 소프트웨어는 가용성 솔루션 및 응용 프로그램과 "잘 작동"되어야합니다. SIOS 기술 고객 경험 담당 부사장으로서 지나치게 공격적인 바이러스 스캐너가 애플리케이션과 가용성 솔루션에 어떤 영향을 미칠 수 있는지 확인했습니다.보안 시스템이 HA / DR 환경에 미치는 영향을 이해하고 보안 목표에 위배되지 않고 함께 작동하는 HA 솔루션을 선택하십시오.

  5. 규제 요건

    데이터 침해는 애플리케이션, 하이퍼 바이저 및 환경의 아키텍처에 영향을 주지만 규제 요구 사항도 마찬가지입니다.글로벌화 된 기업은 이제 여러 국가의 데이터 처리 규정을 준수하는지 확인해야합니다. ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ이는 솔루션을 배포 할 수있는 지역과 중복성을 위해 사용할 수있는 영역 수에 영향을 미칠 수 있습니다.추가 규제 요구 사항은 조직을 지원할 수있는 팀에도 영향을 미칠 수 있으며, 이는 가용성 소프트웨어 및 지원에 대한 선택에 영향을 미칠 수 있습니다.

  6. 창 축소

    연중 무휴 검색, 쇼핑, 게임, 뱅킹 및 조사의 세계에서 창은 줄어들고 있습니다.쿼리는 더 빠르게 실행되고 시간이 더 적게 소요되어야합니다 .. ㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ응답은 더 빨라야하고 더 나은 데이터를 가져야합니다. ㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ즉, 환경에 허용되는 가동 중지 시간이 이전에 생각했던 것보다 빠르게 줄어들고 있습니다.또한 유지 관리 기간이 더 빡빡하고 압축되며 최적화되고 고도로 조정되어야 함을 의미합니다. 애플리케이션 성능과 빠른 복구 시간 모두를 위해 클러스터 구성을 최적화하는 방법에 대한 지침을 제공 할 수있는 HA 공급 업체와 협력하십시오.

  7. 경쟁 압력 증가

    저는 작은 마을에서 자랐습니다. 철물점에는 경쟁자가 하나있었습니다. 식료품 점에는 경쟁자가 하나있었습니다. 서점, 골동품 가게, 자동차 판매점, 렌탈 사무실, 은행은 모두 경쟁자가있었습니다. 오늘날에는 계산대에서 고객을 보는 것 이상을 원하지 않는 수천만 명의 경쟁자가 있습니다. 이 경쟁은 전체 비즈니스의 복잡성에 영향을 미칩니다. 유지 관리 기간, 업그레이드 및 혁신 속도에서 수행 할 수있는 작업과 불가능한 작업에 큰 비중을 둡니다. 5 년에 한 번 업데이트 될 수있는 환경은 프로세서 속도와 메모리의 최적화 및 향상을 몇 초 또는 몇 분 만에 수행 할 수있는 클라우드로 이동했습니다. 한 때 간단한 애플리케이션 목록을 다루는 단일 실행 책이있는 시스템은 이제 "전쟁과 평화"에 더 가까워지고 이익을 높이기 위해 추가되는 프로세스, 제품, 서비스 및 인텔리전스의 증가를 다루면서 동시에 위험과 다운 타임을 줄이기 위해 노력하고 있습니다.

  8. 고 가용성 솔루션 비용

    우리 모두는 무제한 예산이 있기를 바라지 만, 당신이 이용할 수있는 것 사이의 현실은 때때로 약간과 충분하지 않은 것 사이에 있습니다.팀은 종종 소비와 고정 비용, 대기 클러스터의 애플리케이션 라이선스 비용, 가용성 소프트웨어 관련 비용의 균형을 맞춰야합니다.엔터프라이즈 라이선스는 가용성 환경에서 대기 서버에 대해 '삼키기 어려운'가격표를 추가하는 경우가 많습니다.가용성 솔루션을 설계하는 것은 하드 코어 'DIY'팀이더라도 무료가 아닙니다.DIY는 유지 관리, 관리, 소스 제어, 테스트, 배포, 버전 관리 및 버전 제어, 패치 및 패치 관리에 추가 비용이 발생합니다.전문가 팀이 당연히 도전에 응할 수 있지만, 귀사는 더 많은 수익 기회를 창출하기 위해 높은 가치를 지닌 재능을 활용하는 것을 선호 할 것입니다.

  9. 비즈니스 성장

    혁신으로 인한 비즈니스 성장은 이제 팀이 더 중요한 애플리케이션, 더 많은 사이트, 더 많은 사무실 및 액세스 가능하고 가용성이 높은 데이터에 대한 책임이 있음을 의미합니다. 비즈니스가 성장하고 번성함에 따라 확장 및 확장과 관련된 문제가 앞서 언급 한 복잡성을 추가 할뿐만 아니라 준비하고 계획해야하는 항목을 확장 할 수도 있습니다.

  10. 팀 회전율

    환경의 복잡성, 혁신 속도, 비즈니스 성장, 애플리케이션 계층의 발전, 경쟁 환경의 성장은 인프라를 원활하게 운영하기 위해 최고의 인재를 유지해야하는 과제를 가져옵니다.대부분의 회사는 가용성이 무엇보다도 사람, 프로세스, 제품 및 아키텍처의 합병이라는 것을 이해합니다. 따라서 자동화 된 구성, 문서화 된 실행 책자, 인프라 전반에 걸쳐 일관된 HA 전략으로 제품을 활용하여 클러스터링 환경의 복잡성을 줄이는 방법을 찾는 것은 인프라를 설치 및 관리하는 인재를 유지하고 가용성의 핵심 구성 요소를 담당하는 사람들.

현실을 직시하자, 사랑에는 노력과 좋은 의사 소통, 시간, 투자, 기술, 결단력이 필요합니다. 성공적인 관계로가는 지름길은 없습니다.기업 내에서 점점 더 복잡하고 유동적 인 기술 공간이 떠오르는 상황에서 최상의 결과를 달성하는 방법에 대해서도 마찬가지입니다.가용성, 클러스터링, 재해 복구 및 가동 시간은 혁신의 속도, 애플리케이션 및 오케스트레이션의 복잡성, 경쟁 및 성장을 고려하는 심각하고 헌신적 인 논스톱 문화적 변화를 필요로하기 때문에 매우 '젠장'어렵습니다. 응용 프로그램, 데이터베이스 및 중요 인프라를 필요로하는 사람들이 필요할 때 사용할 수 있도록 유지하는 기타 구성 요소.

-Cassius Rhue, 고객 경험 담당 부사장

SIOS에서 재현

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

상속 된 응용 프로그램 가용성 문제를 해결하는 방법

2월 26, 2021 by Jason Aw Leave a Comment

상속 된 응용 프로그램 가용성 문제를 해결하는 방법

 

 

상속 된 응용 프로그램 가용성 문제를 해결하는 방법

엉망을 물려 받았을 때해야 할 일

저는 큰 직계 가족과 선의의 이모, 삼촌, 가족 친구들의 더 큰 그룹에서 자랐습니다.대가족의 일원이었던 사람은 아마도 한 번 이상 물러나거나 선의의 친척이 당신에게 공짜를 주었을 것입니다. 그리고 만약 그렇다면, 그 멋지게 들리는 유산, 소문이 났던 세련된 옷, 또는 오래된“가족 용 자동차”의 표면 아래에 악몽이 숨어있을 수 있다는 것을 알고 있습니다.갑자기 네 바퀴의 갑작스런 재산은 2/3의 돈 구덩이와 1/3의 눈이 아픈 저주처럼 느껴집니다.

그렇다면 복잡한 애플리케이션 가용성 문제를 물려 받았을 때 어떻게해야할까요?일부 DIYers는 쓰레기통을 가져와 새로 시작합니다. 하지만 이것은 HGTV가 아니며 상속 된 가구가 아니라 상속 된 애플리케이션 가용성 문제에 대해 이야기하고 있습니다. 일반적으로 간단하고 계획된 유지 관리를 위해 처음으로 클러스터 전환을 시도하고 응용 프로그램이 오프라인 상태가 될 때 손이 엉망이라는 것을 알고 있습니다.이제 고 가용성 메시지를 상속 받으면 어떻게하나요?

고 가용성 혼란을 상속 할 때에 대한 두 가지 실용적인 팁 (책임을 의미합니다)

I. 연구

조치를 취하기 전에 할 수있는 가장 좋은 방법 중 하나는 가능한 한 빨리 많은 데이터를 수집하는 것입니다.물론 상속 상태는 데이터를 수집해야하는 속도를 나타낼 수 있습니다.응용 프로그램 가용성 문제를 해결하기 위해 조사하는 동안 고려해야 할 몇 가지 주요 사항 :

  1. 이전 소유자. 명령 체계, 권한 범위, 배경, 팀 역학 및 가능한 경우 헌장을 포함하여 구성의 이전 소유자를 조사합니다.원래 조직 구조가 무엇인지 알아보십시오.
  2. 고 가용성 또는 고 가용성을 달성하기 위해 과거에 수행 된 작업과 누락 된 사항을 조사합니다.일부 환경에서는 더 큰 워크 플로를 무시하면서 고 가용성에 대한 초점이 인프라의 일부에 직각으로 집중됩니다. 사용 가능한 요구 사항을 파헤칩니다. 요구 사항이 원래 제시된 이후 구현되거나 추가 된 변경 사항클라우드 마이그레이션 중이라면이 환경을 클라우드로 이동하는 목표를 이해하십시오.
  3. 소유자와 요구 사항은 많은 역사를 제공합니다. 그러나 주요 의사 결정권자가 소프트웨어 및 하드웨어 아키텍처 요구 사항뿐만 아니라 설계 및 솔루션에 대해 선택과 절충을 선택한 이유도 조사하고 싶을 것입니다.이러한 선택이 성공했는지 실패했는지 평가합니다. 연구는 원래 문제와 제안 된 해결책에 초점을 맞춰야합니다.
  4. 당신은 또한 당신이 물려받은 환경이 왜 엉망인 것처럼 느끼는지 고려해 볼 수 있습니다.예를 들어, 문서화 부족, 교육 부족, 설계 세부 사항 부족 또는 누락, 런북 부재 또는 기타 사양 세부 사항 때문입니까?
  5. 가상 머신, 네트워크 및 애플리케이션의 아키텍처를 보완하기 위해 어떤 엔터프라이즈 급 고 가용성 소프트웨어 솔루션이 사용되었는지 조사하십시오. 현재 재직자가 있습니까?그렇지 않다면 이전의 가용성 방법은 무엇 이었습니까?

II. 행위

이 연구를 수집하고 나면 다음 단계는 업데이트, 개선, 구현 또는 교체와 같은 조치를 취하는 것입니다.클러스터 장애 조치가 필요하지 않기를 바라며 실수하지 마십시오.

  1. 업그레이드

    어떤 경우에는 귀하의 연구를 통해 기존 솔루션을 더 잘 이해하고 해당 솔루션을 최신 버전으로 업그레이드 할 수 있습니다.솔직히 우리는 고객과 함께했습니다.전환이 잘못 처리되었습니다. 수년 동안 완벽하게 작동하는 솔루션은 구식이됩니다.

  2. 돌리다

    업그레이드가 보장되지 않는 경우 대안을 고려하십시오. 데이터가 소프트웨어 또는 하드웨어 튜닝, 클라우드 또는 하이브리드로의 마이그레이션, 네트워크 튜닝 또는 기타 식별 된 위험 또는 단일 장애 지점과 같은 다른 개선 영역을 가리키는 경우.환경이 상태 확인을 받아야하거나 워크로드가 증가하면 인스턴스 크기, 디스크 유형 또는 기타 매개 변수가 개선 될 수 있습니다.

  3. 도구

    다른 경우에는 연구를 통해 고 가용성 전략이나 솔루션의 부족과 관련된 놀라운 세부 정보를 발견 할 수 있습니다. 이 경우 연구를 촉매제로 사용하여 고 가용성 솔루션을 설계하고 구현합니다. 이 솔루션은 성공적인 모니터링 및 복구를 위해 엔터프라이즈 급 HA 소프트웨어와 결합 된 프라이빗 클라우드, 퍼블릭 클라우드 또는 하이브리드 클라우드 아키텍처가 필요할 수 있습니다.

  4. 바꾸다

    극단적 인 경우 연구를 통해 현재 환경을 완전히 대체 할 수 있습니다. 고객이나 파트너가 클라우드로 마이그레이션 할 때 필요한 경우가 있습니다. 그러나 그들의 고 가용성 소프트웨어 오퍼링은 클라우드를 지원하지 않았습니다. 많은 애플리케이션이 클라우드 지원을 자랑하지만 어떤 경우에는 현실보다 더 많은 슬라이드웨어입니다.온 프레미스 솔루션이 클라우드를 지원하지 않습니까? 그렇다면 SIOS Protection Suite 제품과 같이 클라우드 여정을 함께 할 수있는 솔루션을 사용하는 것이 유일한 방법 일 수 있습니다.

저는 SIOS 기술의 고객 경험 담당 부사장으로서 이러한 단계의 중요성을 보여주는 상황을 경험했습니다. 서비스 팀이 SIOS Protection Suite 제품을 배포하기 위해 엔터프라이즈 파트너와 협력했을 때였습니다.고객과 공동으로 연구하면서 풍부한 역사를 발견했습니다. 고객은 제한된 수의 다운 타임 또는 가용성 문제가 있다고 공언했습니다. 그러나 우리의 연구에 따르면 지속 불가능하고 고도로 복잡한 경고 계층 구조, 수동으로 실행되는 스크립트, 글로벌 팀 및 함께 뭉쳐진 도구의 엉뚱함이 드러났습니다. 우리는이 정보를 사용하여 홈 메이드 솔루션을 훨씬 더 우아하고 자동화 된 솔루션으로 성공적으로 설계하고 교체 할 수있었습니다. 가장 좋은 점은 자동화 된 모니터링, 복구 및 시스템 장애 조치 보호를 포함하여 마법사 기반이었습니다. 더 이상 kludge는 없습니다. 더 이상 시행 착오를 겪는 DIY가 없습니다. HA / DR 보호를위한 간단하고 안정적인 애플리케이션 장애 복구 및 장애 복구입니다.

여러 애플리케이션 가용성 문제를 물려받은 경우 SIOS Technology Corp의 배포 및 가용성 전문가에게 문의하십시오. 우리 팀은 연구 프로세스를 안내하고 요구 사항을 개선하는 데 도움을 드릴 수 있습니다. 마지막으로 솔루션을 업그레이드, 개선, 교체 또는 구현하여 기업에 더 높은 가용성을 제공하십시오.

– Cassius Rhue, 고객 경험 담당 부사장

SIOS에서 재현

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

Linux 용 SIOS Protection Suite를 사용하는 SQL Server의 고 가용성에 대한 빠른 시작 가이드

2월 18, 2021 by Jason Aw Leave a Comment

Linux 용 SIOS Protection Suite를 사용하는 SQL Server의 고 가용성에 대한 빠른 시작 가이드

 

Linux 용 SIOS Protection Suite를 사용하는 SQL Server의 고 가용성에 대한 빠른 시작 가이드

이 가이드는 Linux 용 SIOS Protection Suite를 사용하는 Microsoft SQL Server 보호를 설명하기위한 것입니다. 여기에 사용 된 환경은 CentOS 7.6을 실행하는 가상 머신이 추가 된 VMware ESXi입니다. Microsoft SQL 2017은 데이터베이스 서버를 만드는 데 사용됩니다. 데이터베이스 및 트랜잭션 로그는 DataKeeper를 사용하여 노드간에 복제 될 로컬 디스크에 저장됩니다. 이는 공유 스토리지가 로컬 디스크의 간단한 대체물로 사용될 수 있음을 보여줍니다.

이 가이드는 여기에서 PDF로 제공됩니다.

필요한 Microsoft 소프트웨어 다운로드

  1. https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup?view=sql-server-ver15에서 SQL 설치에 대한 다음 Microsoft 가이드를 엽니 다.

SQL 환경 구성 계획

다음 구성 설정은이 빠른 시작 가이드에서 설명하는 클러스터 환경을 만드는 데 사용됩니다. 특정 시스템 환경에 따라 구성 설정을 조정하십시오.

일반 구성

  1. 이 빠른 시작 가이드에서 설치 한 예제는 CentOS를 사용합니다. CentOS는 Red Hat과 바이너리 호환되므로 Red Hat 지침이 적용됩니다.
  2. 이 빠른 시작 가이드의 예는 VMware 환경, 클라우드 또는 물리적 설치에서 실행되는지 여부에 관계없이 매우 유사합니다.

노드 1 구성

  • 호스트 이름 : IMAMSSQL-1
  • 공용 IP : 192.168.4.21
  • 사설 IP : 10.1.4.21
  • / dev / sdb (10GiB)
  • / dev / sdc (10GiB)

노드 2 구성

  • 호스트 이름 : IMAMSSQL-2
  • 공용 IP : 192.168.4.22
  • 사설 IP : 10.1.4.22
  • / dev / sdb (10GiB)
  • / dev / sdc (10GiB)

SQL 액세스에 사용되는 가상 IP

  • 168.4.20, 이것은 LifeKeeper에 의해 보호되며 노드 사이의 "부동"

운영 체제

  • CentOS 7.6

SQL 데이터베이스 구성

  • SQL 데이터베이스 :
  • SQL 가상 호스트 이름 : IMAMSSQL
  • SQL 가상 IP : 192.168.4.20

SQL 파일 시스템 마운트 지점

  • / database / data
  • / database / xlog

설치를위한 시스템 준비

MS-SQL 설치

초기 SQL 설치

이 섹션에서는 Linux OS에 Microsoft 패키지 위치를 추가 한 다음 OS에 SQL Server를 설치하도록 지시합니다.

  1. SQL Server 설치에 대한 다음 Microsoft 가이드를 엽니 다.
    https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup?view=sql-server-ver15
  2. 루트 권한으로 로그인하거나 각 명령 전에 sudo를 사용합니다.
  3. curl -o /etc/yum.repos.d/mssql-server.repo https://packages.microsoft.com/config/rhel/7/mssql-server-2017.repo
  4. yum 설치 -y mssql-server
  5. / opt / mssql / bin / mssql-conf setup, 평가 라이선스로 SQL Server를 설치했습니다.
  6. yum install -y mssql-tools unixODBC-devel
  7. echo‘export PATH =”$ PATH : / opt / mssql-tools / bin”‘>> ~ / .bash_profile
  8. echo‘export PATH =”$ PATH : / opt / mssql-tools / bin”‘>> ~ / .bashrc
  9. 소스 ~ / .bashrc
  10. systemctl stop mssql-server.service, SQL 서비스를 중지하고 섹션에서 스토리지로 사용되는 디스크를 구성 할 때까지 SQL 서비스를 시작할 수 없습니다.
    "데이터베이스 및 트랜잭션 로그 파일 시스템과 마운트 지점 생성
    ".
  11. / opt / mssql / bin / mssql-conf set filelocation.masterdatafile /database/data/master.mdf
  12. / opt / mssql / bin / mssql-conf set filelocation.masterlogfile /database/xlog/mastlog.ldf

데이터베이스 및 트랜잭션 로그 파일 시스템과 마운트 지점 생성

이 설치에는 xfs 파일 시스템 유형을 사용합니다. 구성 할 파일 시스템을 결정하려면 LifeKeeper 지원 파일 시스템 유형을 참조하십시오. GUID 식별자를 사용하도록 디스크를 구성해야합니다. 여기서는 로컬로 연결된 디스크를 분할하고 포맷합니다. SQL이 사용할 데이터베이스 위치를 마운트, 생성 및 권한 부여한 후 마지막으로 지정한 위치에 새 마스터 DB 및 트랜잭션 로그를 생성하는 SQL을 시작합니다. 파티션을 생성 할 때 DataKeeper는 파티션의 블록 수가 홀수 여야합니다. 예 : 20973567 (끝) – 2048 (시작) = 20971519.

  1. fdisk / dev / sdb
  2. mkfs -t xfs / dev / sdb1
  3. fdisk / dev / sdc
  4. mkfs -t xfs / dev / sdc1
  5. mkdir / database; mkdir / database / data; mkdir / database / xlog
  6. chown mssql / database /; chgrp mssql / 데이터베이스 /
  7. chown mssql / database / data /; chgrp mssql / 데이터베이스 / 데이터 /
  8. chown mssql / database / xlog /; chgrp mssql / database / xlog /
  9. vi / etc / fstab
    1. / dev / sdb1 마운트를 / database / data에 추가합니다. / dev / sdb1 / database / data xfs 기본값 0 0
    2. / dev / sdb1 마운트를 / database / xlog에 추가합니다. / dev / sdb1 / database / xlog xfs 기본값 0 0
  10. 마운트 / dev / sdb1
  11. 마운트 / dev / sdc1
  12. chown mssql / database / data /; chgrp mssql / 데이터베이스 / 데이터 /
  13. chown mssql / database / xlog /; chgrp mssql / database / xlog /
  14. systemctl start mssql-server.service, 로컬 디스크가 마운트되었으므로 이제 SQL 서비스를 시작합니다. 그러면 새 마스터 DB 및 트랜잭션 로그가 생성됩니다.

LifeKeeper 설치

설치 가이드를 참조하십시오
http://docs.us.sios.com/spslinux/9.5.1/en/topic/sios-protection-suite-for-linux-installation-guide

LifeKeeper 리소스 계층 생성

기본 노드에서 LifeKeeper GUI를 엽니 다.

# / opt / LifeKeeper / bin / lkGUIapp &

통신 경로

백엔드 및 / 또는 프런트 엔드 IP 경로를 만듭니다.이 경우 백엔드는 10.2.4.21 및 22이고 프런트 엔드는 192.168.4.21 및 22입니다.

  1. [AWS only] AWS Management Console에서 각 인스턴스를 마우스 오른쪽 버튼으로 클릭하고 네트워킹 → 소스 / 대상 변경을 선택합니다. 소스 / 대상 확인이 사용 중지되었는지 확인하고 확인합니다.
  2. LifeKeeper GUI에서 통신 경로 만들기를 클릭합니다.
  3. 원격 서버 대화 상자에서 다른 클러스터 노드의 호스트 이름을 추가하고 선택합니다.

 

  1. 적절한 로컬 (10.2.4.21) 및 원격 (10.2.4.22) IP 주소를 선택합니다.
  2. 이 프로세스를 반복하여 각 네트워크의 모든 원격 노드 쌍 사이에 통신 경로를 만듭니다 (예 : 12.0.1.30 및 12.0.2.30).완료 후 모든 클러스터 노드 쌍 사이에 통신 경로가 있어야합니다.

IP 리소스

IP 리소스는 SQL 서버에 액세스하는 데 사용되는 가상 IP입니다 (이 경우 192.168.4.20).

  1. 다음을 실행하여 모든 가상 IP가 네트워크 인터페이스에서 제거되었는지 확인합니다.
    ‘ip addr show’.
  2. MSSQL 가상 IP에 대한 IP 리소스를 만듭니다.
  3. LifeKeeper GUI에서 리소스 계층 구조 만들기를 클릭하고 IP를 선택합니다.

4. 메시지가 표시되면 IP 192.168.4.20을 입력하고 서브넷 마스크 255.255.0.0을 선택합니다.

5. ip-192.168.4.20-MSSQL과 같은 태그 이름을 입력합니다.

DataKeeper 리소스

데이터베이스 및 트랜잭션 로그, / database / data 및 / database / xlog를 저장하는 데 사용되는 드라이브입니다.

데이터 복제 리소스

  1. 모든 SQL 파일 시스템이 기본 클러스터 노드의 / database 아래에있는 적절한 마운트 지점에 마운트되었는지 확인하십시오.
    # 마운트
    …
    / database / data type xfs의 / dev / sdb1 (rw, relatime, attr2, inode64, noquota)

/ database / xlog 유형 xfs의 / dev / sdc1 (rw, relatime, attr2, inode64, noquota)
…

2. 파일 시스템이 백업 클러스터 노드에 마운트되어 있지 않은지 확인합니다.

삼.LifeKeeper GUI에서 리소스 계층 구조 만들기를 클릭하고 데이터 복제를 선택합니다.

4. 계층 유형에서 기존 파일 시스템 복제를 선택합니다.

5. 기존 마운트 포인트에 대해 / database / data를 선택하십시오.

6. 환경에 적합한 나머지 생성 대화 상자에 대해 적절한 값을 선택합니다.

/ database / data 및 / database / xlog 파일 시스템에 대해 3-6 단계를 반복합니다.

빠른 서비스 보호

LifeKeeper의 Quick Service Protection ARK를 사용하여 mssql-server 서비스를 보호하고 MSSQL 서비스를 모니터링하고 실행 중인지 확인합니다.

  1. 노드 1에서 systemctl status mssql-server.service를 사용하여 MSSQL이 실행 중인지 확인합니다.
  2. 노드 2에서 systemctl status mssql-server.service를 사용하여 MSSQL이 실행되고 있지 않은지 확인합니다. 실행중인 경우 systemctl stop mssql-server.service를 사용하여 서비스를 중지 한 다음 / database / data 및 / database를 마운트 해제해야합니다. / xlog 디렉토리.
  3. LifeKeeper GUI에서 리소스 추가를 클릭합니다.
  4. 드롭 다운에서 QSP ARK를 선택합니다.
  5. 사용 가능한 서비스 목록이 채워지면 mssql-server.service를 선택합니다.
  6. 환경에 적합한 나머지 생성 대화 상자에 대해 적절한 값을 선택합니다.
  7. 계층 구조를 노드 2로 확장
  8. 노드 1의 Linux CLI에서“/ opt / LifeKeeper / bin / lkpolicy -g –v”를 실행하면 다음과 유사한 출력이 표시됩니다.
  9. QSP-mssql-server에 대해 LocalRecovery : On이 설정된 경우 두 노드에서 로컬 복구를 비활성화해야합니다.이 작업은 다음을 실행하여 수행됩니다 (두 노드에서 모두).
  10. / opt / LifeKeeper / bin / lkpolicy -s LocalRecovery -E tag =”QSP-mssql-server”
  11. 두 노드 "/ opt / LifeKeeper / bin / lkpolicy -g –v"에서 로컬 복구가 비활성화되어 있는지 확인합니다.

SIOS에서 재현

Filed Under: 서버 클러스터 단순화 Tagged With: 설치

  • « Previous Page
  • 1
  • …
  • 54
  • 55
  • 56
  • 57
  • 58
  • …
  • 98
  • Next Page »

최근 게시물

  • SIOS LifeKeeper 데모: AWS에서 롤링 업데이트 및 장애 조치가 PostgreSQL을 보호하는 방법
  • 네트워크 카드를 교체해야 하는지 평가하는 방법
  • SIOS Technology, Red Hat Summit, Milestone Technology Day 및 XPerience Day, SQLBits 2025에서 미션 크리티컬 애플리케이션을 위한 고가용성 클러스터링 소프트웨어 시연
  • 고가용성과 관련된 애플리케이션 인텔리전스
  • Nutanix 환경에서 고가용성 솔루션을 선택하기 위한 10가지 고려 사항

가장 인기있는 게시물

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

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