오늘 이 블로그에서는 퍼블릭 도메인과 네임 서버 토픽에 대해 논의하겠습니다. 관리자와 아키텍트에게 중요한 토픽 중 하나입니다. 또한, 이는 데이터 센터 종료 시나리오나 분할 및 인수 시 주요 토픽 중 하나입니다. 먼저 Azure 퍼블릭 DNS 존에 대해 이야기해 보겠습니다.
Azure 공용 DNS 영역:
이것은 Azure의 무기고에 있는 DNS 서비스 중 하나입니다.이름에서 알 수 있듯이 이것은 개인 이름 확인이 아닌 공개 이름 확인을 위한 DNS 서비스입니다.개인 DNS 이름 확인을 위해 개인 DNS 영역이 있습니다.따라서 기본적으로 GoDaddy와 같은 DNS 등록 기관에서 공개 도메인 이름을 소유하고 있고 해당 도메인 이름에 대한 자체 이름 서버를 관리해야 하는 경우 Azure Public DNS Zone 서비스를 사용할 수 있습니다.이름 서버는 도메인에 대한 모든 레코드가 호스팅되는 곳입니다.기본적으로 GoDaddy와 이러한 많은 도메인 등록 기관은 이름 서버를 무료로 제공합니다.예를 들어 GoDaddy 도메인을 소유한 경우 아래 스크린샷을 확인할 수 있으며 GoDaddy가 도메인 이름에 대한 이름 서버를 소유하고 있습니다.
레코드가 게시되면 DNS 전파를 제외하고 공개되기까지 24시간이 걸리는 도메인 등록 기관이 있습니다.또 다른 시나리오는 많은 등록 기관이 이메일을 사용하여 통신하고 지원이 때때로 지연되는 것입니다.따라서 마이그레이션 중에 레코드를 관리하는 데 시간이 걸립니다.또한 때로는 이름 서버의 가용성이 문제가 될 수 있습니다.이름 서버를 사용할 수 없으면 클라이언트가 IP 주소를 확인할 수 없습니다.이름 서버를 직접 호스팅하여 이름 서버의 소유권을 가질 수 있습니다.Azure Public DNS Zone은 고가용성이 내장되어 있고 100% SLA를 제공하는 관리형 서비스입니다 .그렇습니다.공개 DNS 영역은 글로벌 서비스이므로 100% SLA입니다.도메인의 이름 서버를 알고 싶다면 nslookup을 사용하여 이름 서버 레코드를 찾을 수 있습니다.
Azure Public DNS 존의 네임 서버는 아래와 같습니다. 이는 단지 예시일 뿐입니다. DNS 존을 만들면 도메인의 네임 서버 레코드를 받게 됩니다.
Microsoft.com과 azure.com도 Azure Public DNS Zone에 호스팅됩니다.
퍼블릭 DNS 존을 만들면 아래와 같습니다. 제공된 네 개의 네임 서버 레코드를 볼 수 있습니다. 이를 네임 서버 레코드로 사용하여 DNS 등록자에게 제공해야 합니다. 네임 서버를 기본 DNS 등록자의 NS 레코드에서 Azure의 NS 레코드로 변경하면 Azure 퍼블릭 DNS 존에 있는 레코드가 권한이 있고 활성화됩니다.
레코드를 만들 수 있습니다. 레코드 세트 섹션으로 가서 모든 레코드를 만드세요.
Azure Public DNS로 이름 서버를 마이그레이션하기 전에 Azure Public DNS Zone에 모든 레코드를 만들었는지 확인해야 합니다. 예를 들어 GoDaddy 또는 다른 공급자에 www.xyz.com 레코드를 만든 경우 Azure DNS Zone에 유사한 A 레코드를 만들었는지 확인해야 합니다. Azure Public DNS Zone을 만들었다고 해서 퍼블릭 레지스트라에서 DNS 이름을 구매한 것은 아닙니다. Azure Public DNS Zone은 이름 서버 역할을 할 뿐입니다. 여전히 Godaddy, Squarespace, Namecheap 등과 같은 DNS 레지스트라에서 퍼블릭 도메인 이름을 소유해야 합니다. 여기서 Azure에서 도메인을 구매하는 또 다른 주제로 넘어갑니다.
Azure App Service 도메인:
Azure에서 직접 도메인을 구매할 수 있습니다. 이는 새 웹사이트를 배포하거나 새 프로젝트를 진행하는 경우 타사 등록 기관을 통해 도메인을 구매하고 싶지 않을 때 발생합니다. Microsoft는 ICANN에 등록된 등록 기관이지만 Microsoft는 최종 고객에게 직접 퍼블릭 도메인을 제공하지 않습니다. 이는 GoDaddy를 통해 라우팅됩니다. 따라서 Azure App Service Domain에서 도메인을 구매할 때마다 Azure에 비용을 지불하고 이 경우 GoDaddy와 직접 거래하지 않습니다.
Azure에서 구매하고 GoDaddy를 통해 구매하지 않는 이유는 무엇일까요? 조달 팀에 대한 의존성 없음, Azure에서 직접 도메인을 빠르게 배포하고 단일 공급업체(Microsoft)에 지불하는 것이 몇 가지 이유가 될 수 있습니다.
App Service Domain을 배포할 때마다 호스팅 레코드를 위해 Azure Public DNS와 통합됩니다. DNS 레코드 관리를 클릭하면 Azure DNS 페이지를 찾을 수 있습니다. 이름 서버 레코드는 처음부터 Azure DNS로 자동으로 업데이트됩니다.
점점 더 많은 고객이 마이그레이션 대상으로 Azure VMware Solution을 탐색하기를 요청하고 있으므로 많은 아키텍트와 사전 판매 담당자의 가장 흔하고 첫 번째 문제 중 하나를 해결하는 것에 대해 생각해 보았습니다. Azure VMware Solution 노드의 크기를 조정하는 방법은 무엇입니까? AVS 설계에 관련된 네트워크 설계 및 구성 요소를 살펴보기 전에. 대부분의 경우 고객은 온프레미스 워크로드에 맞는 노드 수와 해당 노드의 비용을 결정해야 합니다.
이 블로그 전체에서 vCPU, 메모리, 스토리지에 집중하는 이유는 무엇일까요? AVS 노드는 특정 크기로 제공되기 때문입니다. 예를 들어, AV36p의 한 노드는 36개의 물리적 코어, 768GB 메모리, 19.20TB NVMe 스토리지를 갖습니다. 배포에 필요한 노드 수를 알아내야 합니다. 그리고 그에 따라 노드를 계속 추가하게 됩니다.
Manual Method: 이 방법은 주로 사용 중인 vCPU 수, 메모리 및 스토리지에 따라 AVS 노드 크기를 조정하는 것을 포함합니다. 따라서 기본적으로 VMware 클러스터의 현재 크기에 따라 AVS 노드 크기를 조정하게 됩니다. 이는 예산 크기 조정일 수도 있는데, VM에 vCPU가 16개 있지만 4개만 사용하는 경우 AVS 노드의 전체 크기 조정에서 여전히 16개의 vCPU를 고려하고 실제 사용률은 고려하지 않기 때문입니다.
Azure Migrate Method: 이 방법에서는 Azure Migrate와 같은 도구를 사용하여 평균 또는 최대 부하를 기준으로 VM 사용률을 계산하고 이를 기준으로 AVS 노드 크기를 정확하게 조정하는 데 도움이 됩니다. 이는 VM에 대해 16개의 vCPU를 구성했지만 4개만 사용하더라도 4개의 vCPU만 고려하기 때문에 적절한 크기입니다. 따라서 크기가 정확하고 적절합니다. 사용 가능한 또 다른 방법은 RVTools 가져오기 기반 평가입니다. 이는 수동 방법에서 달성하는 것과 마찬가지로 있는 그대로의 크기입니다. 다만 UI 중심적이며 수동 계산이 포함되지 않습니다.
어플라이언스 기반 방법과 관련된 단점은 도구를 실행하고 일정 기간 동안 성능 지표를 캡처하는 데 시간이 필요합니다. AVS 노드의 크기를 즉시 조정하거나 예산 견적이 필요한 경우 있는 그대로 기반 크기를 선택할 수 있습니다.
수동 방법을 사용하여 있는 그대로 크기를 조정하고 VMware 환경에서 모든 VM의 vCPU, 메모리 및 스토리지 사용률을 파악하는 데 RVTools는 이상적인 도구로 돋보입니다.
Manual Method
대부분 VMware 관리자는 RVTools를 통해 VMware 클러스터를 내보내는 방법을 알고 있을 것입니다. 그렇지 않은 경우 웹사이트https://www.robware.net/home에서 도구를 다운로드할 수 있습니다. 필요한 세부 정보가 포함된 'vminfo'를 포함하여 여러 탭이 있습니다. 이 탭에서 관련 숫자를 합산합니다.
CPU: VM과 연결된 vCPU를 보여줍니다.
메모리: 여기에는 할당된 메모리가 포함됩니다.
사용 중 MiB: 현재 사용된 저장소 용량을 보여줍니다.
프로비저닝된 MiB: 여기에는 할당된 스토리지가 포함됩니다. 스토리지는 외부 스토리지의 도움으로 요구 사항에 따라 확장될 수 있으므로 이 열은 고려하지 않을 것입니다. 따라서 In-use-MiB만 고려합니다.
AVS 노드 크기:
총 vCPU, 메모리 및 사용 중인 스토리지를 구하면 Azure 노드가 제공할 수 있는 것과 비교해야 합니다. 예를 들어 보겠습니다. AVS 노드 3개(최소)는 아래 크기를 제공합니다. CPU 및 메모리 요구 사항에 따라 배포 크기를 적절히 조정해야 합니다. 스토리지 고려 사항은 약간 다르며 다음 섹션에서 노드에서 사용 가능한 공간을 계산하는 방법에 대해 자세히 알아보겠습니다. 그러나 노드 크기를 조정할 때는 주로 vCPU와 메모리를 고려해야 합니다. Azure NetApp 파일이나 Azure Elastic SAN과 같은 원격 스토리지 옵션을 사용하여 스토리지를 확장할 수 있기 때문입니다. 이 시나리오에서는 스토리지 요구 사항에 맞게 노드 수를 늘릴 필요가 없습니다.
이제 rvtools 크기에 따라 필요한 총 vCPU, 메모리 및 스토리지를 파악하고 요구 사항에 맞게 AVS 노드 수를 조정할 수 있습니다.
저장 크기:
AVS 노드에서 RAW 스토리지를 얻고, 사용 가능한 공간은 아래 언급된 여러 요인에 따라 달라집니다.
VM 스토리지 정책을 생성할 때 선택하는 RAID(RAID 1, 5 또는 6)
저장 정책 중 선택한 FTT(FTT 1, 2, 3)
Slack 공간 사용 가능(SLA를 얻으려면 최소 25%의 여유 공간이 필요함)
체크섬(평균 5%)
공간 효율성 비율(1.50 – 평균이지만 저장되는 데이터와 얻는 공간 효율성에 따라 다릅니다. 증가할 수도 있음) AVS의 저장 및 고려 사항에 대해 자세히 알고 싶다면 이 주제에 대한 이전 블로그를 참조할 수 있습니다.
위에서 언급한 요인 때문에 사용 가능한 공간이 다를 수 있습니다. 빠른 계산을 위해 가장 사용 가능한 스토리지를 제공하는 AV36P에 대한 RAID 크기를 아래에 캡처했습니다. FTT를 2에서 3으로 늘리려면 사용 가능한 스토리지는 적지만 더 높은 복원력을 제공합니다. AVS의 SLA에 따라 노드가 6개 이상인 경우 최소 FTT 2를 선택해야 합니다.
고려 사항: -
체크섬: 5%
여유 공간: 25%
공간 효율성 비율: 1.50
크기 조정의 예
AVS 노드 수를 구하는 방법의 한 가지 예를 들어보겠습니다. rvtool을 사용한 후 500개의 vCPU와 3.5TB 메모리가 필요하고, 이와 함께 90TB의 사용 가능한 스토리지가 필요하다는 것을 알게 되었습니다. AVS 크기 조정을 위해 AV36p SKU를 고려해 보겠습니다. 이와 함께 1:4의 CPU 오버커밋을 고려해 보겠습니다. 따라서 1:4 오버커밋으로 500개의 vCPU를 맞추려면 4개의 노드, 36 x 4 = 144개의 물리적 코어, 144 x 4 = 576개의 vCPU가 필요합니다. 그러나 AVS AV36p의 4개 노드를 사용하면 768 x 4 = 3072GB의 메모리만 얻을 수 있습니다. 따라서 3.5TB의 메모리를 맞추려면 노드가 하나 더 필요하므로 총 5개의 AV36p 노드가 필요합니다. 4개의 노드를 선택하는 데 메모리가 병목 현상이 되기 때문입니다. 5개의 AVS 노드를 사용하면 최대 77.6TB의 사용 가능한 스토리지만 받게 되므로 ANF 또는 ESAN에서 추가 스토리지를 얻을 수 있습니다. 따라서 외부 스토리지는 크기 조정에 12.37TB가 필요합니다. 여기 있습니다. 전체 마이그레이션에 필요한 5개의 AV36p 노드입니다.
하지만 이는 있는 그대로의 크기이고 CPU 세대와 NVMe 스토리지에 따라 실제 요구 사항이 감소할 수 있습니다. 기본적으로 배포하는 동안 최소 3개 노드의 클러스터 배포로 시작하여 VM을 마이그레이션하고 더 높은 메모리와 vCPU가 필요할 때 노드 수를 늘리기 시작합니다.
Azure Migrate based sizing
위의 크기 조정은 수동 방법을 사용하여 수행했습니다. Azure Migrate를 사용하면 더 자동화된 방식으로 크기를 조정할 수 있습니다. Azure Migrate를 통해 수행하더라도 저장소 크기 조정 및 CPU 오버커밋에 대한 메트릭과 매개변수는 동일하게 유지됩니다. Azure Migrate를 사용하여 수행할 수 있는 두 가지 주요 AVS 크기 조정 유형이 있습니다.
어플라이언스 기반: Azure Migrate 어플라이언스 설치 및 성능 평가 또는 있는 그대로에 따라 크기 조정 내보내기
가져오기 기반: rvtools export를 사용하면 Excel 파일을 Azure Migrate 프로젝트로 가져올 수도 있으며, 이를 통해 있는 그대로의 크기 조정이 가능합니다.
Appliance Based
첫 번째 옵션에 대해 이야기해 보겠습니다.이것은 대상이 Azure VM일 때 사용된 프로세스와 매우 유사합니다.즉, Azure Migrate 어플라이언스를 설치하고 vCenter 서버 세부 정보를 추가하고 VM의 성능 기록을 수집하도록 합니다.여기서 유일한 변경 사항은 Azure VM 기반 평가 보고서를 만드는 대신 AVS 평가를 선택한 다음 크기 조정에 대한 매개변수를 제공해야 한다는 것입니다.이 경우 성능 기반 평가를 수행하여 VM의 vCPU, 메모리 성능을 확인한 다음 AVS 노드에 대한 권장 사항을 제공할 수 있습니다.있는 그대로를 원하는 경우 이를 수행하고 현재 vCPU 및 VM의 메모리를 기반으로 AVS 노드 수를 제공할 수도 있습니다.
Azure Migrate 기반 어플라이언스를 사용하여 모든 서버를 발견했다고 가정하고 평가를 만드는 방법으로 넘어가겠습니다.
AVS 평가 선택.
검색 소스가 Azure Migrate Appliance로 선택되어 있는지 확인합니다.
출력이 이러한 선택에 따라 결정되므로 올바른 매개변수 집합을 선택했는지 확인하세요.
평가할 서버를 선택하세요.
AVS 평가가 생성되면 보고서의 출력입니다. 여기에는 필요한 노드 수와 스토리지도 표시됩니다.
Import Based
이는 RVTools 가져오기 방법을 기반으로 하는 있는 그대로의 크기입니다. 저장소와 노드에 필요한 수동 계산은 없습니다. Azure Migrate 프로젝트에서 가져와야 하는 rvtool 도구 내보내기 데이터가 필요하며, AVS 노드 크기 및 필요한 저장소를 제공하기 위해 계산을 수행합니다. 이는 Azure Migrate를 통해 이루어지지만 이 방법에서는 어플라이언스 설치가 필요하지 않습니다. 현재 미리보기 상태입니다.
평가를 생성하기 전에 RVtools를 가져와서 모든 서버가 검색된 서버에 표시되도록 해야 합니다.
RVTools의 미리보기 옵션 선택
검색된 서버에는 rvtools 데이터가 채워져 있습니다.
이제 다시 평가를 생성하지만 이번에는 Azure Migrate 어플라이언스 대신 가져온 서버를 선택하게 됩니다.
서버 선택.
평가 만들기.
이제 평가 화면 출력에 AVS 평가 수가 1로 표시됩니다.
이 화면에서는 생성된 평가의 총 수가 표시됩니다.
평가판을 열면 저장 공간과 함께 필요한 AVS 노드의 전체 크기가 표시됩니다.
Azure 가격 계산기를 사용하여 AVS 비용 계산
이 섹션에서는 Azure 가격 계산기를 통해 샘플 AVS 사이징을 해보겠습니다. Express Route Gateway, Azure Route 서버 또는 방화벽과 같은 네트워킹 구성 요소를 추가하지 않고, 랜딩 존이 구성되고 준비되기를 바라며 AVS 자체 비용이 얼마일지 추정할 뿐입니다.
VNet-VNet 연결 구성은 간단하게 VNet을 연결할 수 있는 방법입니다. VNet-VNet 연결 형식(VNet2VNet)을 사용하여 가상 네트워크를 다른 가상 네트워크에 연결하는 것은 온-프레미스 위치에 사이트 간 IPsec 연결을 설정하는 것과 비슷합니다. 두 연결 형식 모두 VPN 게이트웨이를 사용하여 IPsec/IKE를 통한 보안 터널을 제공하며 둘 다 동일한 방식으로 통신합니다. 그러나 로컬 네트워크 게이트웨이를 구성하는 방법이 다릅니다.
VNet-VNet 연결을 설정할 때 로컬 네트워크 게이트웨이 주소 공간이 자동으로 생성되고 채워집니다. 한 VNet의 주소 공간을 업데이트하면 다른 VNet이 자동으로 업데이트된 주소 공간으로 라우팅됩니다. 일반적으로 사이트 간 연결보다는 VNet-VNet 연결이 더 빠르고 쉽습니다.
- 출처 : Microsoft -
* 사전준비
- 네트워크 구성도는 아래와 같이 구성한 상태에서 VNET간 VPN Gateway 설정을 통해 연결해보겠습니다.
* 실습요약
1. Virtual Network Gateway 생성
2. Virtual Network Gateway Connect 생성
1. Virtual Network Gateway 생성
vnet1gw
vnet2gw
각 가상 네트워크에 위와 같이 설정하여 Virtual Network Gateway를 생성합니다.
2. Virtual Network Gateway Connect 생성
'vnet1-to-vnet2' 라는 이름의 Virtual Network Gateway Connect를 위와 같이 생성합니다.
'vnet2-to-vnet1' 라는 이름의 Virtual Network Gateway Connect를 위와 같이 생성합니다.
위와 같이 연결 두 개가 생성되었고 상태가 '연결됨' 으로 바뀌었습니다.
(연결까지 3~5분 소요)
vnet1-vnet2 연결을 보면 가상 네트워크가 연결된 것을 볼 수 있으며,
데이터의 흐름에 따라 입력과 출력값을 확인할 수 있습니다.
vm-test-01 가상머신으로 원격 데스크톱 연결하여 vm-test-02의 사설IP 주소인 10.41.0.4 로 ping을 보냈을 때 정상적으로 연결되는 것을 확인할 수 있습니다.
BGP는 소규모 네트워크 망을 위한 프로토콜이 아닌 대규모 네트워크 망에 적합한 라우팅 프로토콜 입니다. 그리고 OSPF, RIB, EIGRP 와 같은 IGP (Inter Gateway Protocol)는 Fast Convergence에 중점을 두지만 BGP는 Fast Convergence가 아닌 안정성에 더 중점을 두고 맞춰서 설계된 라우팅 프로토콜 입니다.
●BGP (Border Gateway Protocol) 특징
TCP를 이용한 신뢰성 있는 라우팅 업데이트 수행 - TCP Port 179을 사용하여 Neighbor 사이 신뢰 관계를 맺고, 업데이트가 누락되지 않도록 합니다.
KeepAlive를 이용한 Neighbor 상태 확인 - KeepAlive를 이용하여 Neighbor의 상태를 확인 합니다. 기본적인 Timer는 Hello TIme 60초, Hold Time 180초 이며 Hold TIme 이내 Hello 메시지가 들어오지 않으면 Neighbor가 죽은 것으로 판단 합니다.
주기적인 BGP 업데이트 수행 - iBGP는 5초, eBGP는 30초 간격으로 BGP 업데이트가 수행 됩니다. 라우팅에 변화가 생길 때 마다 업데이트가 발생하게 되면 네트워크 자원소모가 많기 때문에 일정 주기로 업데이트가 수행 됩니다. 업데이트 간격 사이에 발생하는 변화는 반영하지 않고 최종 상태만 업데이트를 수행 합니다.
최적 경로 선출을 위한 다양한 기준 - IGP와 달리 BGP는 최적 경로 선출을 위해 CISCO 기준 11개의 기준이 있으며 해당 값을 비교하여 최적 경로로 선출 된 항목만 라우팅 테이블에 내려 갑니다. 최적 경로로 선출되지 못하더라도 BGP Table에는 존재 합니다.
다양한 경로 속성 (Well-Known속성과 Optional 속성) - BGP는 경로 정보 전달 시 다양한 정보를 전달 합니다. 경로 정보에 포함되는 정보는Well-Known 속성과 Optional 속성이 존재 합니다. Well-Known 속성은 다시 Mandatory과 Discretionary로 분류 되며 모든 장비에서 지원 합니다. Optional 속성은 전달 가능한 속성 (Transitive Optional Attribute)와 전달 하지 못하는 속성 (Non-Transitive Optional Attribute)로 나뉘며 장비에 따라 지원여부를 확인해 보아야 합니다.
BGP 경로 속성을 이용한 트래픽 조절 - Local AS에서 외부로 경로를 전송할 때는 다양한 방법(Weight, Local Preference, ETC...)으로 제어가 가능하지만 유입되는 트래픽을 조절 할 수 있는 방법이 AS Path를 추가하는 방법만 존재 합니다.
인접하지 않아도 BGP Neighbor 관계 수립 가능 - 다른 라우팅 프로토콜과 달리 BGP는 인접하지 않은 라우터와도 BGP Neighbor 관계를 맺을 수 있습니다. Neighbor를 맺기 위해 사용되는 IP까지 도달할 수 있다면 Neighbor 관계를 맺는데 문제가 없습니다.
다양한 프로토콜 지원 (MP-BGP) - RFC 2858번이 추가 되면서 BGP는 IP 이외 다른 프로토콜들도 지원 할 수 있게 되면서 MP BGP라는 이름으로 얻게 되었습니다. address family identifier (AFI)는 IPv4, IPv6와 관련이 있고, subsequent addressfamily identifier (SAFI)를 이용하여 유니캐스트 또는 멀티캐스트 트래픽 전송이 가능해졌습니다.
원래 BGP는 IPv4만 수용 가능했기에 BGP Database Table을 하나만 관리 했으나 AFI 와 SAFI 기능이 추가 되면서 BGP Database는 address family와 sub-address family 기준으로 별도로 생성되고 관리 됩니다.
BGP를 구성하는 방법은 일반적으로 Single-Homing, Dual-Homing, Multi-Homing 3가지를 소개합니다. 시간이 지나며 용어의 변경이 발생하여 Dual-Homing은 모두 Multi-Homing 방법으로 소개 되고 있으며, Single-Homing 방법은 굳이 BGP를 사용할 필요가 없어 소개 되지 않습니다.
Redundancy와 Traffic Handling 목적으로 BGP 세션을 추가로 맺습니다. BGP 세션을 맺는 방법에 따라 4가지의 시나리오를 생각할 수 있습니다.
○BGP (Border Gateway Protocol) Multi-Homing Design 종류
구성
설명
■ Client가 동일한 SP (Service Provider) Router와 eBGP 세션을 맺는 방법 입니다. eBGP Peer가 2개가 생기지만 Best-Path Selection Algorithm에 의해서 하나의 경로만 사용 가능하며 주 목적은 Link Redundancy 입니다.
■ AS Prepending or MED를 사용하여 유입되는 트래픽을 조절할 수 있습니다. (A, C 트래픽은 Line 1, B,D 트래픽은 Line 2 로 들어오게 조절 가능)
■ 단일 SP Router와 eBGP 세션을 맺기 때문에 Client or SP측 네트워크 장비에 문제가 발생 하거나 내부 네트워크에 문제가 발생 또는 Client Router에 문제가 발생하면 장애가 발생합니다.
■ Client가 동일한 SP를 사용하지만 서로 다른 Router와 eBGP 세션을 맺는 방법 입니다.eBGP Peer가 2개가 생기지만 Best-Path Selection Algorithm에 의해서 하나의 경로만 사용 가능하며 주 목적은 Link or Device Redundancy 입니다.
■ AS Prepending or MED를 사용하여 유입되는 트래픽을 조절할 수 있습니다. (A, C 트래픽은 Line 1, B,D 트래픽은 Line 2 로 들어오게 조절 가능)
■ 동일 SP의 다른 라우터와 BGP 세션을 맺기 때문에 장비 장애에 대비할 수 있지만 SP 내부 네트워크에 문제가 발생 또는 Client Router에 문제가 발생하면 장애가 발생합니다.
■ Client가 서로 다른 SP와 eBGP 세션을 맺는 방법 입니다. 다른 SP에 연결 되기 때문에 Link & Device Redundancy 효과와 SP내부 네트워크 장애가 발생하더라도 서비스는 유지 됩니다.
■ 서로 다른 AS로 부터 BGP 정보를 받아오기 때문에 AS Path 기준으로 서로 다른 경로가 선택 될 수 있어 동일 SP에 연결하는 구조보다 더 최적화된 트래픽 관리가 가능 합니다.
■ Client Router는 단일 장비이기 때문에 단일 실패 지점이 될 수 있으며, Transit Network가 되지 않도록 필터링이 필요 합니다.
■ Client Router를 iBGP로 연동하고 서로 다른 SP와 eBGP 연결을 수행 합니다.Link & Device Redundancy 효과와 SP내부 네트워크 장애 그리고 Client Router에 문제가 발생하더라도 서비스는 유지 됩니다.
■ 가장 일반적으로 사용하는 eBGP를 맺는 방법 입니다. 서로 달느 AS와 연결되기 때문에 Transit Network가 되지 않도록 필터링이 필요 합니다.
● BGP Transit Network
Transit Netwok란 고객의 네트워크가 SP 네트워크 처럼 동작되어 다른 네트워크 트래픽이 우리 네트워크를 경유해서 전달되는 것을 의미 합니다. 고객은 SP와 eBGP를 연결할 때 Transit Network가 되지 않도록 네트워크 필터링을 설정 해 주어야 합니다.
회사 BGP 네트워크가 위와 같은 환경으로 구성되어 있을 경우 SP3은 10.64.1.0/24 네트워크 정보를 2가지 경로를 통해 학습 합니다. 하나는 SP1 - SP2 - SP4의 경로를 통해 학습하고 다른 하나는 SP4 - AS500을 통해 학습 합니다. BGP 최적 경로 선출 알고리즘에 의해 AS PATH가 짧은 SP4 - AS500 의 경로가 최적 경로로 선출 되고 고객 네트워크인 AS500이 의도치 않게 Transit Network로 동작 하게 됩니다.
Transit Network로 동작하지 않도록 하기 위해 SP와 연결하는 라우터는 필터링을 통해서 Transit Network로 동작하지 않도록 해야 합니다. 일반적으로 SP와 연결 할 때 정규식(Regular Expression)을 이용하여 Local AS만 광고하고 SP로 부터는 BGP 정보를 받지 않는 정책을 가장 많이 사용 합니다.
BGP Session 관계를 맺는 AS에 따라 iBGP와 eBGP 2가지 타입으로 분류가 되며 서로 다른 특성을 부여 받게 됩니다.
Internal BGP (iBGP) - 같은 AS 번호 아래에 있는 라우터와 BGP 관계를 맺거나 같은 BGP Confederation 에 참여하고 라우터와 BGP 관계를 맺을 때 iBGP라고 합니다. iBGP에게 전달 받은 경로의 AD (Administrative Distance)는 200으로 Routing Table에 표기 됩니다.
External BGP (eBGP) - 다른 AS 번호에 소속 되어 있는 라우터와 BGP 관계를 맺을 때 eBGP라고 합니다. eBGP에게 전달 받은 경로의 AD는 20으로 Routing Table에 표기 됩니다.
○ iBGP
같은 AS내에서 BGP 관계가 필요한 이유는 다양한 라우팅 정책이 필요하거나 AS 번호 사이에서 경로 정보를 전달 할 때 누락되지 않아야 하기 때문입니다.
AS 65100과 AS 65300 사이에 위치한 "AS 65200"은 BGP로 전달 받은 경로 정보를 누락없이 전달해야 하기 때문에 BGP 관계를 맺어 전달하는 것이 가장 안전 합니다. R2와 R4는 iBGP 관계를 맺어 eBGP로 받은 경로 정보를 안정적으로 전달 할 수 있습니다.
R3은 BGP Neighbor 관계를 맺고 있지 않기 때문에 외부 AS로 가는 경로를 알지 못합니다. R3이 외부 AS경로를 학습하기 위해서는 BGP 라우터의 재분배를 통해 경로정보를 학습할 수 있지만 유연성이 저해되고, BGP 정책이 누락 되기 때문에 재분배 대신 BGP를 사용하는 것이 일반적 입니다.
다만, iBGP는 학습한 경로를 1 HOP 떨어진 iBGP로만 전달 할 수 있는 제약이 있습니다. (R2가 광고하는 외부 경로 정보는 R3까지 전달되고 R4까지 전달 되지 않습니다.) 이런 제약을 극복하기 위해 iBGP Full-Mesh 구조로 구성하거나 RR (Route Reflector)를 구성하여 사용 합니다.
○eBGP
서로 다른 AS에 속해 있는 라우터간 Neighbor 관계를 맺으면 eBGP가 됩니다. 외부와 연결되는 eBGP는 iBGP와 비교하여 아래와 같은 차이점이 존재 합니다.
eBGP의 TIme-To-Live (TTL)값은 1이 기본값 입니다. Multi-Hop eBGP Neighbor 관계를 맺기 위해 TTL값을 늘려줘야 합니다. iBGP의 TTL값은 255 입니다.
eBGP가 경로를 광고하면 Local AS 번호가 추가 됩니다. eBGP는 수신한 경로 정보에 Local AS 번호가 포함되어 있으면 Routing Loop라고 판단하고 해당 경로정보를 버립니다.
eBGP Neighbor 관계를 맺을 때는 물리 인터페이스에 부여된 주소를 사용하고 iBGP Neighbor 관계를 맺을 때는 Loopback 인터페이스 주소를 사용하는 것이 일반적 입니다.
iBGP와 eBGP 구성을 위한 설정의 근간은 remote-as를 제외하고 크게 다르지 않으나, 세부적으로 Neighbor 관계를 맺기 위한 인터페이스 선정, Next-Hop 문제, TTL, AD, iBGP Update Issue 및 기타등등 등이 존재하기 때문에 이 부분을 고려하여 설정 하여야 합니다.
BGP 최적 경로 선출기준은 IGP 보다 풍부하며 또한 선출 기준에 따라 우선순위가 있습니다. 또한 최적 경로 선택 알고리즘은 AS로 들어오는 트래픽 또는 나가는 트래픽에 영향을 줍니다.
●BGP (Border Gateway Protocol) 최적 경로 선출 기준
BGP 경로 광고에는 Network Layer Reachability Information (NLRI)와 Path Attributes (PAs)가 포함되어 있습니다. NLRI는 Network Prefix, Network Prefix Length와 AS Path, Origin 같은 정보들로 이루어져 있습니다. BGP Table에는 동일한 목적지에 대해 여러개의 경로가 있으며, 경로에 포함된 속성들이 최적 경로 선출에 영향을 주게 됩니다.
해당 속성들을 이용하여 BGP는 최적 경로를 선출하게 됩니다. 최적 경로 선출에 사용되는 기준은 총 11가지가 있습니다. 우선순위가 높은 기준이 먼저소개 됩니다. (오름차순)
Longest Matching Rule 적용 - 가장 상세한 경로정보를 우선시 하는 기준으로 최적 경로 선출시 가장 먼저 적용됩니다. 다음과 같이 경로 정보를 수신한다면 192.168.0.0/16 보다 192.168.1.0/24 경로 정보를 우선 시 하게 됩니다. /24보다는 /25 를 더 우선 합니다.
Weight (Cisco Only) - Cisco 장비에서만 적용되는 우선순위로 Local BGP 라우터에서 수신한 BGP경로가 다수 있을 때 최적 경로 선출에 사용되는 기준이며, 해당 값은 다른 BGP 라우터에게 전달 되지 않습니다. - Weight 값의 범위는 0 부터 65,535 까지이며 Weight 값은 inbound route-map을 통해 설정하거나 특정 Neighbor에게 Weight 값을 설정하여 사용 합니다.
Local Preference (LOCAL_PREF or LP) - Local Preference는 Well-Known Discretionary Path Attribute이며 BGP 업데이트 메시지에 포함되는 속성 입니다. Local Preference는 eBGP에게 전달 되지 않으며 iBGP에서 최적 경로 선출 목적으로 사용 됩니다. - 0부터 4,294,967,295사이의 값을 가질 수 있으며 기본값은 100 입니다. LP 값이 높은 경로가 최적 경로로 선출 됩니다.
Local Originated (Network Statement, Redistribution, Aggregation) - 외부 Peer에 의해 BGP 테이블에 삽입된 경로 보다, Locally Router가 Network 명령어를 통해 BGP 테이블에 삽입한 경로를 우선시 합니다.
AIGP (Accumulated Interior Gateway Protocol) - Accumulated IGP (AIGP) 는Optional Non-Transitive경로 속성이며, AS 내부에서만 전달이 되는 값 입니다.IGP의 경로를 BGP에 재분배하고, IGP의 메트릭 값을 이용하여 BGP가 최적 경로 선출에 사용 합니다. AIGP를 BGP Peer에게 전달하기 위해 Route-Map을 사용해야 합니다.
다수의 BGP AS를 관리하는 환경에서 사용 가능하며, IGP에 사용되는 IP 주소체계가 겹치지 않고 고유해야 하는 제약사항이 있습니다. 일반적인 엔터프라이즈 환경에서 적합하지 않습니다.
Shortest AS Path - 목적지로 향하는 다양한 경로가 존재할 경우, 가장 짧은 AS 길이를 가진 경로를 선호 합니다. BGP에서 AS는 HOP Count와 같으며 짧을 수록 우선순위가 높습니다. 해당 규칙을 이용하여 BGP 트래픽 유입을 제어할 수 있습니다. AS Prepending을 사용하여 AS를 추가할 수 있습니다.
Origin Type - Well-known mandatory BGP 속성 입니다. Network 명령어를 통해서 광고한 경로는 IGP or i 의 코드를 받고 재분배 네트워크는 imcomplete or ? 코드를 받습니다.IGP를 더 선호 합니다.
Lowest MED (Multiple-Exit Discriminator) - Optional Non-Transitive속성이며 32 bit 값 (0 to 4,294,967,295)으로 표현하며 메트릭 이라고 부릅니다. BGP에서 네트워크를 광고 또는 재분배 할 때 IGP 경로 메트릭을 자동으로 설정하며 eBGP에게 경로를 학습할 때 MED값을 전달 받지 못한다면 기본값은 0 입니다. 만약 MED를 eBGP에게 수신한다면 다른 iBGP Peer에게 전달 하지만 다시 eBGP에게 전달하진 않습니다.
MED값을 MED 사용의 목적은 다른 Inbound Traffic을 제어하기 위한 목적으로 사용되며낮은 MED를 더 선호 합니다.
eBGP Over iBGP - BGP 경로를 학습하는 방법은 iBGP, eBPG, Confederation AS에게 받는 3가지 방법이 있으며, 이중에서 eBGP Peer에게 받은 경로를 가장 선호 합니다. eBGP > Confederation AS > iBGP 우선순위를 가집니다.
Lowest IGP Next-Hop Metric - BGP Next-Hop 주소의 IGP 메트릭 값이 가장 낮은 것을 선호 합니다. 낮은 것을 선호하는 이유는 Next Hop의 IGP Metric값이 낮으면 Next-Hop까지 더 빨리 도달하기 때문 입니다.
Oldest Path Prefer eBGP - 상기 조건까지 모두 동일하다면 BGP 테이블에 먼저 학습된 경로를 선호 합니다. 가장 오래된 eBGP 경로이기 때문에 더 안정적이라 판단 합니다.
Lowest BGP Router ID - 가장 낮은 Router ID를 가진 eBGP 라우터를 더 선호합니다. 만약 경로를 Route Reflextor로 부터 받았다면 Router ID 대신 Originator ID를 사용 합니다.
Minium Cluster list Length - The cluster list 는 non-transitive BGP 속성이며 최소 Cluster List 길이를 더 선호 합니다. Route Reflector가 Cluster ID를 Cluster List에 추가하며 Route Reflector는 해당 정보를 이용하여 Routing Loop가 발생하지 않도록 합니다.
Lowest Neighbor Address - BGP Peer가 2개의 물리적인 링크를 통해 Neighbor 관계를 맺을 경우 가장 낮은 Neighbor 주소를 가진 경로를 더 선호 합니다. iBGP Peer 한정으로 적용되는 규칙으로 Neighbor 주소가 가장 낮은 것을 선호 합니다. (eBGP이 경우 오래된 경로를 우선 한다는 규칙이 있어 여기에는 해당 하지 않습니다.)
이 비디오에서는 Azure Migrate Server Assessment를 사용하여 Azure VMware Solution(AVS)에 대한 마이그레이션 및 용량 계획을 수행하는 단계를 안내합니다. 비디오 콘텐츠: 00:00 - 소개 00:59 - Azure Migrate Assessment 상위 수준 단계 02:37 - 데모: Azure Migrate 프로젝트 만들기 03:51 - 데모: 온프레미스 VM 검색 09:50 - 데모: Azure Migrate Assessment 만들기 11:53 - 데모: Azure Migrate Assessment 검토
