| 9월 10, 2020 |
Linux 환경에서 SQL Server에 대한 고 가용성을 제공하는 방법
Linux 환경에서 SQL Server에 대한 고 가용성을 제공하는 방법조직이 Linux에서 업무상 중요한 Microsoft SQL Server를 실행하는 경우 IT 팀은 의심 할 여지없이 고 가용성, 성능 및 보안을 지속적으로 유지 관리하는 것이 얼마나 어려운지 알고 있습니다. 특히 어려운 것은 강력한 복제 및 자동 장애 조치로 고 가용성을 보장하는 방법입니다. 오픈 소스 소프트웨어와 쉽게 구성 할 수있는 HA SANless 클러스터 솔루션을 사용하면 조직에 필요한 안전과 성능을 희생하지 않고도보다 간단한 유지 관리 방식을 제공 할 수 있습니다. Linux에 대한 제한된 고 가용성 옵션대부분의 Linux 배포판은 IT 부서에 고 가용성을위한 두 가지 열등한 선택을 제공합니다. SQL Server Enterprise Edition에 Always On 가용성 그룹을 구현하는 데 더 많은 비용을 지불하거나 복잡한 DIY HA Linux 구성이 제대로 작동하도록하는 데 어려움을 겪는 것입니다. 하기 어렵다. Enterprise Edition 사용의 문제점은 상용 하드웨어에서 오픈 소스 운영 체제를 사용하기위한 비용 절감 전략을 약화 시킨다는 것입니다. 제한된 수의 소규모 SQL Server 응용 프로그램의 경우 추가 비용을 정당화 할 수 있습니다. 그러나 많은 데이터베이스 애플리케이션에 비해 너무 비싸고 Linux 용 범용 HA를 제공하는 데 아무 일도하지 않습니다. Pacemaker 및 Corosync 또는 SUSE Linux Enterprise High Availability Extension과 같은 오픈 소스 소프트웨어를 사용하여 Linux 환경에서 실행되는 모든 애플리케이션에 HA를 제공 할 수 있습니다. 그러나 전체 소프트웨어 스택이 원하는대로 작동하려면 각 응용 프로그램에 대한 사용자 지정 스크립트를 만들고 테스트해야하며 이러한 스크립트는 사용중인 소프트웨어 나 하드웨어를 약간 변경 한 후에도 종종 다시 테스트하고 업데이트해야합니다. SQL Server Standard Edition과 Linux 모두에서 지원되지 않는 가용성 관련 기능은 이러한 노력을 더욱 어렵게 만들 수 있습니다. Linux에서 SQL Server를위한 대체 고 가용성 솔루션 찾기HA를 비용 효율적이고 쉽게 구현하기 위해 두 가지 다른 범용 접근 방식을 고려할 수 있습니다. 하나는 중복되고 탄력적 인 SAN (Storage Area Network) 내에서 데이터를 복제하여 데이터를 보호하는 스토리지 기반 시스템을 사용하는 것입니다. 이 접근 방식은 호스트 운영 체제와 관련이 없지만 전체 SAN 인프라를 단일 공급 업체로부터 확보해야하며 고 가용성을 제공하기 위해 별도의 장애 조치 프로비저닝에 의존해야합니다. 다른 접근 방식은 호스트 기반이며 Linux 서버 인스턴스에서 스토리지에 구애받지 않는 SANless 클러스터를 만드는 것입니다. HA 오버레이로서 이러한 클러스터는 사설, 공용 및 하이브리드 클라우드의 LAN과 WAN 모두에서 작동 할 수 있습니다. 또한 오버레이는 애플리케이션에 구애받지 않으므로 조직이 모든 애플리케이션에서 단일 범용 HA 솔루션을 가질 수 있습니다. 이 접근 방식은 호스트 리소스를 소비하지만 비교적 저렴하고 Linux 환경에서 쉽게 확장 할 수 있습니다. 대부분의 HA SANless 클러스터 옵션은 실시간 블록 수준 데이터 복제, 지속적인 애플리케이션 모니터링, 구성 가능한 장애 조치 / 장애 복구 정책의 조합을 제공하여 Standard Edition에서 사용할 수있는 Always On 장애 조치 클러스터 인스턴스를 사용하는 애플리케이션을 포함하여 모든 비즈니스 크리티컬 애플리케이션을 보호합니다. SQL Server의. SIOS Technology Corp.는 컴퓨팅 인프라를 지원하고 최적화하는 복잡성과 일상적인 문제에서 IT를 해방하도록 설계된 고급 기능을 갖춘 Linux 용보다 강력한 HA SANless 클러스터 솔루션을 제공합니다. LifeKeeper가 포함 된 SIOS Protection Suite 솔루션은 다음을 제공합니다.
예를 들어 SANless 클러스터는 두 개의 동시 오류를 처리 할 수 있습니다. 기본 작동은 LAN 및 WAN뿐만 아니라 사설, 공용 및 하이브리드 클라우드에서 동일합니다.
일반적인 2 노드 클러스터에서 서버 # 1은 처음에 데이터를 서버 #에 복제하는 기본 서버입니다. 문제가 발생하여 이제 기본 서버가되는 서버 # 2에 대한 장애 조치가 자동으로 트리거됩니다. 이 상황에서 IT 부서는 서버 # 1의 장애를 유발 한 모든 문제를 진단하고 수리하기 시작할 것입니다. 일단 수정되면 주 서버 또는 서버 # 2가 해당 용량에서 계속해서 데이터를 서버 # 1에 복제 할 수 있으므로 인계 될 수 있습니다. 대부분의 HA SANless 클러스터링 구성에서 장애 조치는 자동이며 브라우저 기반 콘솔에서 장애 조치와 장애 복구를 모두 제어 할 수 있습니다. SIOS LifeKeeper 및 Protection Suite 솔루션에 대한 자세한 내용은 클러스터 서버 환경 용 SIOS SAN 및 SANless 고 가용성 클러스터를 참조하세요. SIOS의 허가를 받아 복제 |
| 9월 6, 2020 |
SIOS 클러스터링 소프트웨어에 대한 라이센스를 활성화하는 방법 |
| 8월 30, 2020 |
Apache 다운 타임을 없앤다면?
|
| 8월 25, 2020 |
Linux 구성에 대한 SIOS Protection Suite 복원을위한 팁
Linux 구성에 대한 SIOS Protection Suite 복원을위한 팁"임의의 동료"잘하셨습니다! 그리고 좋은 직업이라고해서 정말 좋은 직업을 의미하지는 않았습니다. 그리고“Random Coworker”란 체크하지 말아야 할 상자를 체크하거나 체크를 해제 한 사람, 메시지와 경고를 생략 한 남녀, 안전 대책을 Linux 용 SIOS Protection Suite 구성을 망쳤습니다. 우리 모두 거기에있었습니다. 사고였습니다. 그러나 그것은 일어났습니다. 갑자기 당신은 상사가 알아 내기 전에 구성, 데이터 및 "무엇이든"을 복구하기 위해 무엇을해야하는지 파악하려고 애 쓰고 있습니다. SIOS Technology Corp.의 고객 경험 담당 부사장으로서 우리 팀은 파트너 및 고객과 적극적으로 협력하여 시스템을 다운 타임으로부터 보호하기 위해 엔터프라이즈 가용성을 설계하고 구현하고 있습니다. 사고가 발생하고 최근 고객 경험을 통해 여러 번의 확인 및 경고를 받았음에도 불구하고 Linux 용 SIOS Protection Suite 제품도 우발적 인 구성 변경에 영향을받지는 않지만“Random Coworker 's에서 빠른 복구를위한 간단한 팁이 있습니다. "우연한 실수. 실수로 구성을 변경 한 후 Linux 용 SIOS Protection Suite를 복구하는 방법Linux 용 SIOS Protection Suite (SPS-L)의 기본은 / opt / LifeKeeper / bin / lkbackup 아래에있는 lkbackup이라는 도구입니다. 이름에서 알 수 있듯이이 도구는 SPS-L 구성 세부 정보의 백업을 생성합니다. 참고 :이 도구는 모든 애플리케이션 데이터를 백업하지는 않지만 리소스 정의, / etc / default / LifeKeeper 파일에 구성된 튜너 블, 고객이 만든 일반 등 SPS-L 구성에 대한 모든 데이터의 백업을 만듭니다. 응용 프로그램 스크립트, 클러스터 상태와 관련된 플래그, 통신 경로 / 클러스터 정의 등. [root@baymax ~ ] # / opt / LifeKeeper / bin / lkbackup -c -f /root/mylkbackup-5.15.2020-v9.4.1 –cluster –ssh 예 : : lkbackup create 구문 그러면 / root 폴더 아래에 mylkbackup-5.15.2020-v9.4.1이라는 백업 파일이 생성됩니다. –cluster는 lkbackup에 각 클러스터 노드에 동일한 파일을 만들도록 지시합니다. –ssh는 ssh 프로토콜을 사용하여 각 클러스터 노드에 연결합니다. 추가 lkbackup 세부 정보는 다음과 같습니다. 고객 경험 서비스 팀은 업그레이드, 리소스 제거 또는 추가 또는 구성 변경과 같은 SPS-L 구성 변경을 수행하기 전에 백업을 수행 할 것을 권장합니다. 따라서 SPS-L 구성을 복원해야하는 경우 변경은 lkbackup을 다시 실행하는 것만 큼 간단합니다. [root@baymax ~ ] # / opt / LifeKeeper / bin / lkbackup -x -f /root/mylkbackup-5.15.2020-v9.4.1 –cluster –ssh 예 : lkbackup 복원 구문 자동 백업 기능은 lkbackup 파일을 자동으로 캡처합니다.그러나 "Random Coworker"가 SPS-L 설정 및 구성 시간을 낭비하기 전에 lkbackup을 실행하여이 파일을 만드는 것을 잊은 경우 어떻게해야합니까? SPS-L을 설정 한“Guy”또는“Gal”이 휴가, 육아 또는 출산 휴가 중이면 어떻게합니까? 만약 당신이“무작위 동료”이고 Basis 팀의 Steve가 일이 어떻게 진행되고 있는지 확인하기 위해 복도를 향하고 있다면? 대부분의 설치에서 SIOS는 설치 중에 자동 백업 기능을 활성화합니다. 이 자동 백업 기능은 / opt / LifeKeeper / config / auto-backup에서 현지 시간으로 오전 3시에 lkbackup 파일을 자동으로 캡처합니다. #. tgz [root@baymax ~]# ls -ltr /opt/LifeKeeper/config/auto-backup.*
예. 구성 / 자동 백업 목록의 출력 시스템이 올바르게 설치 및 구성되어 있으면 자동 백업이 매일 밤 실행되어 "무작위 동료"가 발생했을 때이를 처리 할 수 있습니다. 실수하기 전에 SPS-L auto-backup. #. tgz를 찾아 SPS-L lkbackup 도구를 사용하여 Linux 구성 용 SIOS Protection Suite를 검색하고 이전에 구성된 상태로 복원합니다. [root@baymax ~ ] # lkstop; / opt / LifeKeeper / bin / lkbackup -c -f /opt/LifeKeeper/config/auto-backup.0.tgz 예 : 자동 백업을위한 lkbackup 복원 구문 필요에 따라 클러스터의 다른 노드에서이 작업을 반복합니다. 노트. 시스템이 자동 백업 파일을 생성하고 자신의 "Random Coworker"로부터 사용자를 보호하도록 구성되어 있지 않은 경우 SIOS는 SIOS 전문 서비스 엔지니어가 수행하는 설치 및 구성 서비스와 구성 상태 확인을 제공합니다. — Cassius Rhue, VP, 고객 경험 SIOS의 허가를 받아 복제 |
| 8월 18, 2020 |
단계별 : Amazon EC2에서 SANless MySQL Linux 장애 조치 클러스터를 구성하는 방법
단계별 : Amazon EC2에서 SANless MySQL Linux 장애 조치 클러스터를 구성하는 방법이 단계별 가이드에서는 Amazon의 Elastic Compute Cloud (Amazon EC2)에서 고 가용성 2 노드 MySQL 클러스터 (감시 서버 포함)를 구성하는 데 필요한 모든 단계를 안내합니다. 가이드에는 스크린 샷, 셸 명령 및 코드 조각이 모두 포함되어 있습니다. Amazon EC2에 어느 정도 익숙하고 이미 계정이 있다고 가정합니다. 그렇지 않은 경우 오늘 가입 할 수 있습니다. 또한 Linux 시스템 관리 및 가상 IP 등과 같은 장애 조치 클러스터링 개념에 대한 기본적인 지식이 있다고 가정하겠습니다. 장애 조치 클러스터링은 수년 동안 사용되어 왔습니다. 일반적인 구성에서는 두 개 이상의 노드가 공유 스토리지로 구성되어 기본 노드에서 장애 조치가 발생할 경우 보조 또는 대상 노드가 최신 데이터에 액세스 할 수 있습니다. 공유 스토리지를 사용하면 거의 0에 가까운 복구 지점 목표가 가능할뿐만 아니라 대부분의 클러스터링 소프트웨어에 대한 필수 요구 사항입니다. 그러나 공유 스토리지에는 몇 가지 문제가 있습니다. 첫째, 단일 장애 지점 위험입니다. 공유 스토리지 (일반적으로 SAN)가 실패하면 클러스터의 모든 노드가 실패합니다. 둘째, SAN은 비용이 많이 들고 구매, 설정 및 관리가 복잡 할 수 있습니다. 셋째, Amazon EC2를 포함한 퍼블릭 클라우드의 공유 스토리지는 고 가용성 (99.99 % 가동 시간), 거의 제로에 가까운 복구 시간 및 복구 지점 목표, 재해 복구 보호를 유지하려는 회사에게는 불가능하거나 실용적이지 않습니다. 다음은 엄격한 HA / DR SLA를 충족하면서 이러한 문제를 제거하기 위해 클라우드에서 SANless 클러스터를 생성하는 것이 얼마나 쉬운 지 보여줍니다. 아래 단계에서는 Amazon EC2와 함께 MySQL 데이터베이스를 사용하지만 SQL, SAP, Oracle 또는 기타 애플리케이션을 보호하기 위해 AWS에서 2 노드 클러스터를 생성하는 데 동일한 단계를 적용 할 수 있습니다. 참고 : 기능, 화면 및 버튼보기는 아래에 제시된 스크린 샷과 약간 다를 수 있습니다. 1. Virtual Private Cloud (VPC) 생성 개요이 문서에서는 단일 Amazon EC2 리전 내에서 클러스터를 생성하는 방법을 설명합니다. 클러스터 노드 (node1, node2 및 감시 서버)는 최대 가용성을 위해 서로 다른 가용성 영역에 상주합니다. 이는 또한 노드가 다른 서브넷에 있음을 의미합니다.
다음 IP 주소가 사용됩니다.
1 단계 : Virtual Private Cloud (VPC) 생성먼저 Virtual Private Cloud (VPC라고도 함)를 만듭니다. VPC는 전용 Amazon 클라우드 내의 격리 된 네트워크입니다. IP 주소 블록 및 서브넷, 라우팅 테이블, 보안 그룹 (예 : 방화벽) 등을 완벽하게 제어 할 수 있습니다. 가상 네트워크에 Azure Iaas VM (가상 머신)을 시작합니다. 기본 AWS 대시 보드에서 "VPC"를 선택합니다.
"Your VPCs"아래에서 화면 오른쪽 상단에서 적절한 지역을 선택했는지 확인합니다. 이 가이드에서는 3 개의 가용 영역이있는 리전이므로 "미국 서부 (오레곤)"리전이 사용됩니다. 지역 및 가용 영역에 대한 자세한 내용을 보려면 여기를 클릭하세요.
VPC에 이름을 지정하고 사용할 IP 블록을 지정합니다. 이 가이드에서는 10.0.0.0/16이 사용됩니다.
이제“Your VPCs”화면에 새로 생성 된 VPC가 표시됩니다.
2 단계 : 인터넷 게이트웨이 생성다음으로 인터넷 게이트웨이를 만듭니다. 인스턴스 (VM)가 인터넷과 통신 할 수 있도록하려는 경우 필요합니다. 왼쪽 메뉴에서 인터넷 게이트웨이를 선택하고 인터넷 게이트웨이 만들기 버튼을 클릭합니다. 이름을 지정하고 다음을 만듭니다.
다음으로 인터넷 게이트웨이를 VPC에 연결합니다.
VPC를 선택하고 연결을 클릭합니다.
3 단계 : 서브넷 생성 (가용 영역)다음으로 서브넷 3 개를 만듭니다. 각 서브넷은 자체 가용 영역에 상주합니다. 3 개의 인스턴스 (VM : node1, node2, 감시)는 별도의 서브넷 (따라서 가용 영역)으로 시작되므로 가용 영역의 장애로 인해 클러스터의 여러 노드가 제거되지 않습니다. 미국 서부 (오레곤) 리전 인 us-west-2에는 3 개의 가용성 영역 (us-west-2a, us-west-2b, us-west-2c)이 있습니다. 3 개의 가용성 영역 각각에 하나씩 3 개의 서브넷을 만듭니다. VPC 대시 보드에서 서브넷으로 이동 한 다음 서브넷 생성 :
첫 번째 서브넷에 이름 (“Subnet1)”을 지정하고 가용성 영역 us-west-2a를 선택한 다음 네트워크 블록 (10.0.0.0/24)을 정의합니다.
두 번째 서브넷 가용성 영역 us-west-2b를 생성하려면 반복합니다.
us-west-2c 가용성 영역에 세 번째 서브넷을 생성하려면 반복합니다.
완료되면 아래에 표시된대로 각각 다른 CIDR 블록과 별도의 가용 영역에 3 개의 서브넷이 생성되었는지 확인합니다.
4 단계 : 라우팅 테이블 구성외부로의 트래픽이 이전 단계에서 만든 인터넷 게이트웨이로 전송되도록 VPC의 라우팅 테이블을 업데이트합니다. VPC 대시 보드에서 라우팅 테이블을 선택합니다. Routes 탭으로 이동하면 기본적으로 VPC 내에서만 트래픽을 허용하는 하나의 경로 만 존재합니다. 편집을 클릭하십시오.
다른 경로 추가 :
새 경로의 대상은 "0.0.0.0/0"(인터넷)이고 대상에 대해 인터넷 게이트웨이를 선택합니다. 그런 다음 저장을 클릭합니다.
다음으로 3 개의 서브넷을 라우팅 테이블과 연결합니다. "서브넷 연결"탭을 클릭하고 편집 :
3 개의 서브넷 모두 옆에있는 확인란을 선택하고 저장합니다.
3 개의 서브넷이 기본 라우팅 테이블과 연결되어 있는지 확인합니다.
나중에 돌아와서 라우팅 테이블을 다시 한 번 업데이트하여 트래픽이 클러스터의 가상 IP와 통신 할 수 있도록 라우트를 정의 할 것입니다.하지만 이는 Linux 인스턴스 (VM)가 생성 된 후에 수행되어야합니다. 5 단계 : 보안 그룹 구성들어오는 SSH 및 VNC 트래픽을 허용하도록 보안 그룹 (가상 방화벽)을 수정합니다. 둘 다 나중에 Linux 인스턴스를 구성하고 클러스터 소프트웨어의 설치 / 구성을 구성하는 데 사용됩니다. 왼쪽 메뉴에서 "보안 그룹"을 선택한 다음 "인바운드 규칙"탭을 클릭합니다. 편집을 클릭하십시오.
SSH (포트 22) 및 VNC 모두에 대한 규칙을 추가합니다. VNC는 일반적으로 구성 방법에 따라 5900의 포트를 사용하므로이 가이드의 목적에 따라 5900-5910 포트 범위를 엽니 다. VNC 설정에 따라 구성하십시오.
6 단계 : 인스턴스 시작이 가이드에서는 3 개의 인스턴스 (가상 머신)를 프로비저닝합니다. 처음 두 개의 VM ( "node1"및 "node2"라고 함)은 MySQL 데이터베이스 및 관련 리소스를 온라인 상태로 만드는 기능을 가진 클러스터 노드로 작동합니다. 세 번째 VM은 분할 브레인에 대한 추가 보호를 위해 클러스터의 증인 서버 역할을합니다. 최대한의 가용성을 보장하기 위해 VM 3 개 모두 단일 지역 내의 서로 다른 가용성 영역에 배포됩니다. 이는 각 인스턴스가 다른 서브넷에 있음을 의미합니다. 기본 AWS 대시 보드로 이동하여 EC2를 선택합니다.
"node1"만들기 첫 번째 인스턴스 ( "node1")를 만듭니다. 인스턴스 시작을 클릭합니다.
Linux 배포를 선택하십시오. 나중에 사용되는 클러스터 소프트웨어는 RHEL, SLES, CentOS, Oracle Linux를 지원합니다. 이 가이드에서는 RHEL 7.X를 사용합니다.
그에 따라 인스턴스 크기를 조정하십시오. 이 가이드의 목적과 비용을 최소화하기 위해 t2.micro 크기가 사용되었습니다. 무료 등급이 적용되기 때문입니다. 인스턴스 크기 및 가격에 대한 자세한 내용은 여기를 참조하세요.
다음으로 인스턴스 세부 정보를 구성합니다. 중요 :이 첫 번째 인스턴스 (VM)를 "Subnet1"로 시작하고 서브넷 (10.0.0.0/24)에 유효한 IP 주소를 정의해야합니다. 서브넷의 첫 번째 사용 가능한 IP이므로 10.0.0.4 미만이 선택되었습니다.
다음으로 클러스터 노드에 추가 디스크를 추가합니다 ( "node1"및 "node2"모두에서 수행됨). 이 디스크는 MySQL 데이터베이스를 저장하고 나중에 노드간에 복제됩니다. 참고 : '증인'노드에 디스크를 추가 할 필요가 없습니다. "node1"및 "node2"만. 새 볼륨을 추가하고 원하는 크기를 입력합니다.
인스턴스 Node1에 대한 태그를 정의하십시오.
인스턴스를 기존 보안 그룹과 연결하여 이전에 생성 한 방화벽 규칙이 활성화되도록합니다.
시작을 클릭합니다.
중요 : AWS 환경의 첫 번째 인스턴스 인 경우 새 키 쌍을 만들어야합니다. 비공개 키 파일은 Linux 인스턴스에 SSH로 연결할 때 필요하므로 안전한 위치에 저장해야합니다.
"node2"만들기 위의 단계를 반복하여 두 번째 Linux 인스턴스 (node2)를 만듭니다. Node1과 똑같이 구성하십시오. 하지만 'Subnet2'(us-west-2b 가용성 영역)에 배포해야합니다. Subnet2의 IP 범위는 10.0.1.0/24이므로 여기에서는 IP 10.0.1.4가 사용됩니다.
두 번째 디스크도 Node2에 추가해야합니다. Node1에 추가 한 디스크와 정확히 같은 크기 여야합니다.
두 번째 인스턴스에 태그 지정…. “Node2”:
"증인"만들기 위의 단계를 반복하여 세 번째 Linux 인스턴스 (증인)를 만듭니다. 두 번째 디스크를 추가 할 필요가 없다는 점을 제외하면 Node1 & Node2와 똑같이 구성합니다.이 인스턴스는 클러스터에 대한 감시 역할 만하며 MySQL을 온라인 상태로 만들지 않기 때문입니다. 'Subnet3'(us-west-2c 가용성 영역)에 배포해야합니다. Subnet2의 IP 범위는 10.0.2.0/24이므로 여기에서는 IP 10.0.2.4가 사용됩니다.
참고 : 감시 노드에는 기본 디스크 구성이 좋습니다. 두 번째 디스크는 필요하지 않습니다.
감시 노드에 태그를 지정합니다.
3 개의 인스턴스를 프로비저닝하는 데 약간의 시간이 걸릴 수 있습니다. 완료되면 EC2 콘솔에서 실행중인 것으로 표시됩니다.
7 단계 : 탄력적 IP 생성그런 다음 외부에서 인스턴스에 연결하는 데 사용할 공개 IP 주소 인 탄력적 IP를 만듭니다. 왼쪽 메뉴에서 탄력적 IP를 선택한 다음 "새 주소 할당"을 클릭합니다.
새로 생성 된 탄력적 IP를 선택하고 마우스 오른쪽 버튼을 클릭 한 다음 "Associate Address"를 선택합니다.
이 탄력적 IP를 Node1과 연결합니다.
인터넷 액세스를 원하거나 직접 SSH / VNC 할 수 있도록하려면 다른 두 인스턴스에 대해이 작업을 반복합니다. 8 단계 : 가상 IP에 대한 경로 항목 생성이 시점에서 3 개의 인스턴스가 모두 생성되었으며 클러스터의 가상 IP가 작동하려면 라우팅 테이블을 한 번 더 업데이트해야합니다. 이 다중 서브넷 클러스터 구성에서 가상 IP는 VPC에 할당 된 CIDR 범위 밖에 있어야합니다. 트래픽을 클러스터의 가상 IP (10.1.0.10), 기본 클러스터 노드 (Node1)로 보내는 새 경로를 정의합니다. VPC 대시 보드에서 라우팅 테이블을 선택하고 편집을 클릭합니다. 대상이 Node1 인 "10.1.0.10/32"에 대한 경로를 추가합니다. |
