SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

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

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: 설치

버전 8.7.2 SIOS Protection Suite-Windows 및 DataKeeper Cluster Edition

2월 17, 2021 by Jason Aw Leave a Comment

SIOS Protection Suite 버전 8.7.2-Windows 및 DataKeeper Cluster Edition

SIOS Protection Suite-Windows 및 DataKeeper Cluster Edition 버전 8.7.2 발표

DataKeeper Cluster Edition을 포함한 Windows 용 SIOS Protection Suite 버전 8.7.2의 릴리스를 발표하게되어 기쁘게 생각합니다.새 릴리스의 특징은 다음과 같습니다.

새로운 Oracle PDB (Pluggable Databases) 애플리케이션 복구 키트

  • Oracle Pluggable Database는 Oracle 19c에서 권장되고 Oracle 20c 이상에서 필요합니다.
  • SIOS Protection Suite PDB 애플리케이션 복구 키트에는 추가 SIOS 라이선스가 필요하지 않지만 기존 Oracle 리소스는 필요합니다.

추가 플랫폼 및 운영 체제 지원 : Azure Stack (Hub) (Windows Server 2019 포함), vSphere 7 및 PostgreSQL 12. 지원되는 제품의 전체 목록은 SIOS Protection Suite – Windows 8.7.2 지원 매트릭스를 참조하세요.

SIOS에서 재현

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

SQL Server 장애 조치 클러스터 인스턴스에 Amazon FSX 사용 정보

2월 14, 2021 by Jason Aw Leave a Comment

SQL Server 장애 조치 클러스터 인스턴스에 Amazon FSX 사용 정보

SQL Server 장애 조치 클러스터 인스턴스에 Amazon FSX 사용-알아야 할 사항!

AWS EC2에 자체 Microsoft SQL Server 인스턴스를 배포하려는 경우 솔루션의 복원력과 관련하여 몇 가지 결정을 내릴 수 있습니다. 물론, 서로 다른 가용 영역에 두 개 이상의 인스턴스를 배포하는 경우 AWS는 컴퓨팅 리소스에 대해 99.99 % SLA를 제공합니다. 그러나 속지 마십시오. 진정한 애플리케이션 가용성을 계산할 때 고려해야 할 다른 많은 요소가 있습니다. 최근에 클라우드에서 애플리케이션 가용성을 계산하는 방법에 대해 블로그에 올렸습니다. 계속 진행하기 전에 해당 기사를 빨리 읽어야 할 것입니다.

Microsoft SQL Server 인스턴스의 고 가용성을 보장하는 데 있어서는 Always On 가용성 그룹 (AG) 또는 SQL Server 장애 조치 클러스터 인스턴스 (FCI)의 두 가지 기본 선택이 있습니다. 이 기사를 읽고 있다면이 두 가지 옵션을 모두 잘 알고 있으며 SQL Server Always On AG 대신 SQL Server 장애 조치 클러스터 인스턴스를 사용하는 것을 진지하게 고려하고 있다고 가정하고 있습니다.

Microsoft SQL Server 장애 조치 클러스터 인스턴스의 이점

다음 목록은 AWS가 SQL Server FCI의 이점이라고 말하는 내용을 요약 한 것입니다.

FCI는 일반적으로 다음이 사용 사례의 우선 순위 문제인 경우 SQL Server 고 가용성 배포의 경우 AG보다 선호됩니다.

라이선스 비용 효율성 : AG를 실행하려면 SQL Server의 Enterprise Edition 라이선스가 필요하지만 FCI를 실행하려면 Standard Edition 라이선스 만 필요합니다. 이는 일반적으로 Enterprise Edition보다 50-60 % 저렴합니다. SQL Server 2016부터 Standard Edition에서 AG의 기본 버전을 실행할 수 있지만 AG 당 하나의 데이터베이스 만 지원하는 제한이 있습니다. 이는 SharePoint와 같은 여러 데이터베이스가 필요한 응용 프로그램을 처리 할 때 문제가 될 수 있습니다.

인스턴스 수준 보호 대 데이터베이스 수준 보호 : FCI를 사용하면 전체 인스턴스가 보호됩니다. 기본 노드를 사용할 수 없게되면 전체 인스턴스가 대기 노드로 이동됩니다. 이는 공유 저장소에 물리적으로 저장되는 시스템 데이터베이스에 저장된 SQL Server 로그인, SQL Server 에이전트 작업, 인증서 등을 처리합니다. 반면 AG에서는 그룹의 데이터베이스 만 보호되고 시스템 데이터베이스는 AG에 추가 될 수 없으며 사용자 데이터베이스 만 허용됩니다. 모든 AG 복제본의 시스템 개체에 대한 변경 사항을 복제하는 것은 데이터베이스 관리자의 책임입니다. 이로 인해 인적 오류가 발생하여 데이터베이스가 애플리케이션에 액세스 할 수 없게됩니다.

DTC 기능 지원 : SQL Server 2012 또는 2014를 사용하고 애플리케이션에서 DTC (Distributed Transaction Coordinator)를 사용하는 경우 AG가 지원되지 않으므로 사용할 수 없습니다. 이 상황에서 FCI를 사용하십시오.

https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/

클라우드에서 FCI의 과제

물론이야. 가용성 영역에 걸쳐있는 FCI를 구축하는 데있어 문제는 일반적으로 필요한 공유 저장 장치가 없다는 것입니다. 클러스터의 노드가 여러 데이터 센터에 분산되어 있기 때문에 기존 SAN은 공유 스토리지를위한 실행 가능한 옵션이 아닙니다. 따라서 클러스터 스토리지에는 SIOS DataKeeper와 같은 타사 스토리지 클래스 리소스 또는 새로운 Amazon FSx라는 두 가지 선택이 있습니다.

선택하기 전에 알아야 할 사항을 살펴 보겠습니다.

서비스 수준 계약

애플리케이션 가용성 계산 방법에서 작성한 것처럼 전체 애플리케이션 SLA는 가장 취약한 링크만큼만 좋습니다. 이 경우 99.9 %의 FSx SLA입니다.

일반적으로 99.99 % 가용성은 "고 가용성"으로 간주되는 시작점을 나타냅니다. 두 개 이상의 가용 영역에 배포 될 때 AWS가 컴퓨팅 리소스에 대해 약속하는 것입니다.

3 개의 9와 4 개의 9의 차이를 몰랐다면…

  • 99.9 % 가용성으로 매월 43.83 분의 다운 타임 가능
  • 99.99 %의 가용성으로 매월 4.38 분의 다운 타임 만 허용

99.99 %의 컴퓨팅 가용성에도 불구하고 FSx에서 클러스터 스토리지를 호스팅하면 전체 애플리케이션 가용성이 99.9 %가됩니다. 반대로 DataKeeper 배포와 같이 가용성 영역에 걸쳐있는 EBS 볼륨은 스토리지 및 컴퓨팅 계층 모두에서 99.99 % SLA를 충족합니다. 이는 전체 애플리케이션 가용성이 99.99 %임을 의미합니다.

저장 위치

고 가용성을 위해 FSx를 구성 할 때 다중 AZ 지원을 사용하는 것이 좋습니다. 다중 AZ를 활성화하면 효과적으로 "선호"AZ와 "대기"AZ를 갖게됩니다. SQL Server FCI 노드를 배포 할 때 해당 노드를 동일한 AZ에 배포하려고합니다.

이제 정상적인 상황에서 활성 클러스터 노드가 기본 FSx 스토리지 노드와 동일한 AZ에 있는지 확인해야합니다. 이는 스토리지의 거리와 대기 시간을 최소화하기위한 것입니다. 또한 AZ 간의 데이터 전송과 관련된 비용을 최소화합니다. FSx 가격 가이드에 명시된대로 '파일 시스템에 대한 AZ 간 또는 리전 간 액세스에는 표준 데이터 전송 요금이 적용됩니다.'

SQL Server FCI 오류가 있지만 FSx 오류가 아닌 불행한 상황에서는 저장소와 컴퓨팅을 함께 연결할 메커니즘이 없습니다. FSx가 장애 조치되는 경우 자동으로 기본 가용성 영역으로 장애 조치됩니다. 그러나 모범 사례에 따르면 근본 원인 분석이 수행되고 일반적으로 유지 관리 기간 동안 장애 복구가 발생하도록 예약 될 때까지 보조 노드에서 SQL FCI가 계속 실행됩니다. 이로 인해 스토리지가 다른 AZ에 상주하여 추가 비용이 발생하는 상황이 발생합니다. 현재 수신 및 송신 모두 AZ에서 데이터를 전송하는 비용은 GB 당 $ 0.01입니다.

FSx 및 SQL Server FCI의 상태를 면밀히 주시하지 않으면 월말에 데이터 전송 요금이 표시 될 때까지 다른 지역에서 실행되고 있다는 사실을 알지 못할 수도 있습니다.

반대로 SIOS DataKeeper를 사용하는 구성에서 저장소 장애 조치는 SQL Server FCI 복구의 일부이므로 저장소가 항상 SQL Server 인스턴스로 장애 조치를 수행하도록합니다. 이렇게하면 SQL Server가 항상 활성 노드에 직접 연결된 EBS 볼륨을 읽고 쓸 수 있습니다. DataKeeper는 AZ 또는 리전간에 복제되는 쓰기 작업과 관련된 데이터 전송 비용을 발생시킵니다. 이 데이터 전송 비용은 DataKeeper에서 사용 가능한 압축을 사용하여 최소화 할 수 있습니다.

장애 조치 제어

FSx 다중 서브넷 구성에는 선호 가용성 영역과 대기 가용성이 있습니다. 선호 가용성 영역의 FSx 파일 서버에 오류가 발생하면 대기 AZ의 파일 서버가 복구됩니다. AWS는이 복구 시간이 표준 공유의 경우 약 30 초가 걸린다고보고합니다. 지속적으로 사용 가능한 파일 공유를 사용하여 Microsoft는이 장애 조치 시간이 15 초에 가까울 수 있다고보고합니다. 이 페일 오버 시간 동안 읽기 및 쓰기가 일시 중지 된 브라운 아웃이 발생하지만 복구가 완료되면 계속됩니다.

FSx 다중 사이트에는 자동 장애 복구가 활성화되어 있습니다. 즉, FSx의 계획되지 않은 모든 장애 조치에 대해 계획되지 않은 장애 복구도 발생합니다. 대조적으로, 일반적으로 SQL Server FCI에 계획되지 않은 장애 조치가 발생하면 보조 서버에서 실행 상태로 두거나 몇 시간 후 또는 다음 유지 관리 기간 동안 장애 복구를 예약합니다.

FSX에서 지원되지 않는 SQL SERVER ANALYSIS SERVICES CLUSTER

SSAS를 클러스터링하려면 SIOS DataKeeper와 같은 클러스터 된 디스크 리소스가 필요합니다. SQL Server Analysis Server를 클러스터링하는 방법 백서에는 SMB를 사용할 수 없으며 드라이브 문자가있는 클러스터 드라이브를 사용해야한다고 명시되어 있습니다. 반대로 DataKeeper Volume 리소스는 자체적으로 클러스터 된 디스크로 표시되며 SSAS와 함께 사용할 수 있습니다.

요약

FSx는 Windows 사용자 파일 및 99.9 % 가용성 SLA로 충분한 기타 중요하지 않은 서비스와 같은 일반적인 SMB 사용에 확실히 적합 할 수 있지만, 애플리케이션에 고 가용성 (99.99 %) 또는 확장되는 HA / DR 솔루션이 필요한 경우 FSx는 탁월한 옵션입니다. SIOS DataKeeper가 적합합니다.

Clusteringformeremortals의 허가를 받아 복제

Filed Under: 서버 클러스터 단순화 Tagged With: SQL Server 장애 조치 (Failover) 클러스터 인스턴스

Linux 빠른 서비스 보호를위한 SIOS Protection Suite

2월 6, 2021 by Jason Aw Leave a Comment

SIOS Protection Suite에 사용자 지정 애플리케이션 지원을 추가하는 방법-Linux Quick Service Protection 용 SIOS Protection Suite

Linux 용 SIOS Protection Suite 빠른 서비스 보호 리소스 사용

최근 SIOS 전문 서비스 팀과의 계약에서 한 고객이 Linux 솔루션 용 SIOS Protection Suite로 맞춤형 애플리케이션을 보호하는 방법에 대해 문의했습니다. SIOS Technology Corp.에서 경험이 풍부한 고 가용성 전문가 중 한 명이 고객의 애플리케이션을 이해하고 SIOS가 맞춤 애플리케이션 지원을 위해 제공하는 방법을 마련했습니다.

Linux 용 SIOS Protection Suite는 커스텀 애플리케이션에 고 가용성 및 애플리케이션 모니터링을 추가하는 여러 방법을 제공합니다.이러한 옵션에는 다음이 포함됩니다.

  • 사용자 지정 ARK (응용 프로그램 복구 키트) 만들기 1
  • 일반 응용 프로그램 리소스 계층 만들기
  • 빠른 서비스 보호 리소스 생성
유형 코딩 복잡성 모니터링 회복
사용자 지정 응용 프로그램 복구 키트 리소스 1 제일 높은 제일 높은 제일 높은
일반 응용 프로그램 리소스 매질 높은 높은
빠른 서비스 보호 리소스 낮은 매질 매질

차트에 사용 된 정의

모니터링 – 보호 된 애플리케이션, 데이터베이스 또는 서비스의 가용성, 접근성 및 기능을 결정하는 기능으로 정의됩니다.낮은 수준의 애플리케이션, 데이터베이스 또는 서비스 모니터링은 실행중인 프로세스, pid_file의 존재 여부 또는 실행시 상태 명령이 'true'결과를 반환하는지 확인하는 것과 같은 기본적인 범위를 제공합니다.참고 : '참'또는 '0 (영)'반환 코드는 애플리케이션, 데이터베이스 또는 서비스가 실행 중임을 의미하지 않습니다. 그러나 실행 된 명령이 긍정적 (‘참’또는‘0 (영)’) 상태 결과로 성공적으로 완료 될 수 있다는 사실 만 확인했습니다.최고 수준의 모니터링은 프로세스 상태, ps 출력 또는 시스템 상태 반환과 같은 하위 수준의 방법을 넘어서 애플리케이션의 상태 및 기능을 결정하기 위해 애플리케이션 별 지식이 적용됨을 나타냅니다.최고 수준의 모니터링은 일반적으로 권장되는 상태 확인 작업 순서에 대한 지식, 종속성에 대한 지식, 상태 및 모니터링 명령에서 얻은 결과 분석을 적용합니다.

복구 – 실패한 애플리케이션, 데이터베이스 또는 서비스를 다시 시작하는 기능으로 정의됩니다.낮은 수준의 복구 기능은 다시 시작을위한 명령이 실행되고 명령 실행에서 예상되는 출력을 얻음을 의미합니다.가장 높은 수준의 모니터링은 응용 프로그램, 데이터베이스 또는 서비스를 순서대로 다시 시작하는 방법을 결정하기 위해 응용 프로그램 별 지식이 적용됨을 나타냅니다.이 경우 권장되는 작업 순서, 종속성, 롤백 또는 실패의 기타 관련 수정에 대한 지식이 필요할 수 있습니다. 서비스.

솔루션 : 빠른 서비스 보호 리소스

이 계약에서 고객의 애플리케이션은 시스템 호환성을 가졌습니다. 코딩 방지, 최소한의 모니터링 요구 및 간단한 복구 절차에 대한 전반적인 요구 사항을 기반으로 QSP (Quick Service Protection) 리소스를 권장했습니다.

QSP 리소스는 Linux 리소스 보호용 SIOS Protection Suite에 systemd 서비스 지원을 빠르게 추가하는 데 사용됩니다.고객 Example.com의 경우 애플리케이션을 시작하고 중지하는 데 필요한 최소한의 정의 만 있으면서도 시스템과 호환되는 서비스가 있습니다.

[Unit]

Description = SIOS '있는 그대로'예시 서비스 2020

After = network.target

유형[Service] = 단순

다시 시작 = 항상

RestartSec = 3

사용자 = 루트

ExecStart = / example_app / bin / exampleapp 시작

ExecStop = / example_app / bin / exampleapp 중지

[Install]WantedBy = multi-user.target

Example.com 시스템 파일

SIOS는 Linux 용 SIOS Protection Suite 제품으로 리소스 보호를 시도하기 전에 systemctl을 통해 예제 애플리케이션이 그에 따라 중지되고 시작되는지 확인하도록 권장합니다.

# systemctl 상태 예

* example.service – SIOS '있는 그대로'예시 서비스 2020

로드 됨 :로드 됨 (/usr/lib/systemd/system/example.service; 비활성화 됨; 공급 업체 사전 설정 : 비활성화 됨)

활성 : 비활성 (죽음)

# systemctl 시작 예

# systemctl 상태 예

* example.service – SIOS '있는 그대로'예시 서비스 2020

로드 됨 :로드 됨 (/usr/lib/systemd/system/example.service; 비활성화 됨; 공급 업체 사전 설정 : 비활성화 됨)

활성 : 2020-08-21 금요일 14:53:27 EDT 이후 활성 (실행 중). 5 초 전

메인 PID : 19937 (exampleapp)

C 그룹 : /system.slice/example.service

`-19937 / usr / bin / perl / example_app / bin / exampleapp 시작

# systemctl 중지 예

# systemctl 상태 예

* example.service – SIOS '있는 그대로'예시 서비스 2020

로드 됨 :로드 됨 (/usr/lib/systemd/system/example.service; 비활성화 됨; 공급 업체 사전 설정 : 비활성화 됨)

활성 : 비활성 (죽음)

systemd를 통해 애플리케이션이 올바르게 작동하는지 확인한 후 서비스를 다시 시작하고 서비스가 실행 중인지 확인합니다.

# systemctl 시작 예

# systemctl 상태 예

* example.service – SIOS '있는 그대로'예시 서비스 2020

로드 됨 :로드 됨 (/usr/lib/systemd/system/example.service; 비활성화 됨; 공급 업체 사전 설정 : 비활성화 됨)

활성 : 2020-08-21 금요일 15:59:44 EDT 이후 활성 (실행 중). 3 분 2 초 전

메인 PID : 30740 (exampleapp)

리소스 생성 프로세스에 대한 자세한 내용은 Linux 용 SIOS Protection Suite Quick Service Protection Suite 문서를 참조하세요.

SPS-L UI를 사용하여 전역 UI 리소스 도구 모음에 다음 아이콘으로 표시된 만들기 옵션을 SIOS 글로벌 미국 리소스선택합니다.

생성 마법사가 시작되면 리소스 생성 마법사 창에서 빠른 서비스 보호 옵션을 선택합니다.

'전환 유형'에 대한 다음 프롬프트에서 지능형 전환을 사용할지 자동 전환을 사용할지 선택합니다.

'전환 유형'을 선택하면 맞춤 애플리케이션에 대한 기본 서버를 선택할 수있는 서버 대화 상자가 나타납니다.

(참고 : 서비스에 스토리지가 필요한 경우 스토리지 리소스에 대해 이전에 선택한 것과 동일한 기본 서버를 선택해야합니다.)

서비스 이름 대화 상자에서 사용자 지정 응용 프로그램에 대한 서비스를 찾습니다.

예를 들어 올바른 서비스를 선택한 후 모니터링을 사용 설정할지 또는 사용 중지할지 결정합니다.QSP 리소스에서 제공하는 모니터링에 대한 이해를 얻으려면 설명서를 참조하십시오 .2

다음으로 리소스 태그를 선택합니다.리소스 태그는 IT 팀이 애플리케이션 또는 서비스를 보호하는 SPS-L 리소스를 빠르게 식별하는 데 도움이되는 의미있는 이름이어야합니다.

마지막으로 최종 대화에 따라 리소스 생성 프로세스를 완료합니다.리소스가 생성되면 UI를 사용하여 리소스를 추가 서버로 확장합니다. 필요한 경우 새로 보호 된 사용자 지정 서비스 / 애플리케이션과 스토리지 또는 IP 리소스와 같은 기타 필수 리소스간에 종속성을 만듭니다.


노트
:

1 고객 애플리케이션 복구 키트는 SIOS Technology Corp. 전문 서비스 팀과의 계약을 통해 생성 할 수 있습니다.자세한 내용은 professional-services@us.sios.com으로 문의하십시오.

2 QSP 복구 키트 quickCheck는 간단한 상태 만 수행 할 수 있습니다 (서비스 명령의 '상태'작업 사용). QSP는 서비스가 제공되거나 프로세스가 작동하고 있음을 보장하지 않습니다. 복잡한 시작 및 / 또는 중지가 필요하거나보다 강력한 상태 확인 작업이 필요한 경우 일반 응용 프로그램 또는 사용자 지정 응용 프로그램 ARK를 사용하는 것이 좋습니다.

SIOS에서 재현

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

가용성 경고를 이해하고 이에 대응하는 방법

1월 29, 2021 by Jason Aw Leave a Comment

가용성 경고 이해 및 대응

휴스턴 문제가 있습니다 (또는 가용성 알림을 이해하고 이에 대응하는 방법)

성공적인 실패

휴스턴, 우리에게 문제가 생겼다!이는 수많은 우주 애호가와 영화 팬들에게 Apollo 13 우주 임무의 큰 어려움, 잠재적 인 재난, 위험한 상태를 상기시켜주는 상징적 인 라인입니다. NASA는 이제“성공적인 실패”라고 부르는 임무입니다. 자신의 애플리케이션 가용성 경고를 무시하면 기록에서 결정적인 순간이 아닐 수 있지만 유사한 혼란을 초래할 수도 있습니다.

이제 1970 년으로 돌아갑니다.

“산소 탱크를 일상적으로 휘저어 내부에 손상된 와이어 절연체가 점화되어 서비스 모듈 (SM) 산소 탱크의 내용물이 모두 우주로 배출되는 폭발이 발생했습니다. 호흡과 전력 생산에 필요한 산소가 없으면 SM의 추진 및 생명 유지 시스템이 작동하지 못했습니다. 명령 모듈 (CM) 시스템은 재진입을 위해 남은 자원을 절약하기 위해 종료되어야했으며 승무원은 구명정으로 달 모듈 (LM)으로 이동해야했습니다. 달 착륙이 취소됨에 따라 임무 관제사는 승무원을 집으로 데려 오기 위해 노력했습니다.”

산소 탱크의 폭발로 인해 경보, 경고, 압력 및 전압 강하가 발생하고 통신이 중단되고 이제는 우주 비행사와 미션 컨트롤 간의 유명한 무선 통신이 시작되었습니다.하지만 폭발 후 승무원이 아무 조치도 취하지 않았다면 어떨까요? 폭발을 확인하지 않았고 경고 및 게이지에 응답하지 않았으며 문제가 있음을 Mission Control에 알리지 않았다면 어떻게됩니까?Mission Control이 제어 센터의 대시 보드에서 알림을 받거나 알림을받은 후 지원을 제공하지 않은 경우 어떻게됩니까?팀이 머리를 모래에 묻거나 운명과 우연에 사임하고 그들이 직면 한 실패로부터 배우거나, 즉흥적으로 개선하거나 개선하려고하지 않았다면 어떨까요?그 결과는 비극적이었습니다!다큐멘터리로 만들었을지 모르지만 상징적 인 라인을 특징으로하는 블록버스터 영화는 아닙니다.

환경에서 경고가 트리거되면 어떻게합니까?

A; ert

물론 NASA에서 일하지 않는 한 우주 산책은 일상 활동과는 거리가 멀지 만 Apollo 13에 대한 최근 블로그는 가용성에 대한 질문을 불러 일으 킵니다.환경에서 경고가 트리거되면 어떻게합니까? 그냥 무시 하시나요?경고, 로그 메시지 또는 기타 표시기가 사라질지 확인하기 위해 그것을 경시합니까?이러한 경고, 경고 및 메시지를 비활성화하는 방법을 이해하기 위해 공급 업체 지원에 문의하십니까?아니면“여기에 문제가있어 해결해야합니다”라고 말합니까?

SIOS Technology Corp.의 고객 경험 담당 부사장으로서 우리는 경고와 지표를 모두 경험했습니다.우리는 경고를 무시하고 애플리케이션 임계 값에서 네트워크 불안정성, 잠재적 인 데이터 불일치에 이르기까지 문제를 나타내는 중요한 경고를 해제 한 고객과 함께 열심히 걸어 왔습니다.또한 경고를 확인하고 경보가 울리는 이유를 조사하고 근본 원인을 밝혀 내고 노동의 결실을 즐긴 고객도 보았습니다.이 열매는 안정성, 혁신 및 학습 개선, 또는 재난을 피할 수있는 가장 좋은 보상입니다.

가용성 제품이 경고를 트리거 할 때 수행 할 수있는 4 가지 작업

1. 가용성 경고의 유형과 중요도를 확인합니다.

경고 또는 오류가 경고, 오류 또는 심각한 문제를 나타 냅니까? 중요도를 이해하는 데 도움이되는 좋은 위치는 사용 가능한 문서를 참조하는 것입니다. 제품 문서, 온라인 포럼, 지식 기반 문서 (KBA), 내부 팀 데이터 및 프로세스 매뉴얼을 확인하십시오.

2. 경고의 즉시 성을 평가합니다.

경고 및 오류의 경우 심각한 문제 또는 이벤트로 진행될 가능성중요한 문제 및 경고의 경우 이는 분명 할 수 있지만 평가를 통해 중요한 이벤트도 다음 단계에 대한 지침을 제공합니다. 자체 수정, 문제 격리 또는 즉각적인 에스컬레이션.

3. 추가 소스를 참조하십시오.

경고 조건을 결정하기 위해 액세스 할 수있는 다른 소스는 무엇입니까? 예를 들어 경고가 스토리지와 관련된 경우 스토리지 상태를 노출 할 수있는 다른 도구가 있습니까?문제가 네트워크 경고 인 경우 하이퍼 바이저 도구, 트래픽 도구, NIC 통계 또는 분석을 돕기 위해 배포 된 기타 특수 모니터링 도구가 있습니까?

4. 지원에 문의하십시오.

즉, 확실하지 않은 경우 Mission Control에 알립니다. 유형을 결정하고 즉시 성을 평가하고 추가 소스를 참조한 후 공급 업체에 지원을 요청하는 것이 좋습니다.API 호출 임계 값에 대한 경고는 무해한 것처럼 보일 수 있습니다. 그러나 이러한 한도에 도달하면 API 호출이 실패하면 즉각적인 조치를 취할 수 있습니다. 전문가의 권한을 얻는 것은 마음의 평화를 유지하고 재난을 피하는 데 도움이 될 수 있습니다.

SIOS와 같은 숙련 된 공급 업체가 문제의 원인을 신속하게 파악하고 최상의 솔루션을 추천하는 데 도움을 줄 수 있습니다.

가용성 환경의 문제를 반복적으로 무시하면 예상치 못한 결과가 발생할 수 있지만 그다지 치명적인 결과는 아닙니다. 알림, 로그 메시지, 경고 표시기 또는 기타 설치 및 구성된 표시기로 표시된 문제를 해결하면 재해가 발생하기 전에 고객, 비즈니스, 팀 및 자신에게 '문제를 해결할 기회'가 제공됩니다. 동시에 가용성 전략과 인프라를 강화합니다.어느 쪽을 선택 하시겠습니까?

– Cassius Rhue, VP, 고객 경험

SIOS에서 재현

 

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

  • « Previous Page
  • 1
  • …
  • 69
  • 70
  • 71
  • 72
  • 73
  • …
  • 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