'Endpoint'에 해당되는 글 3건

  1. 2018.12.11 AWS - VPC : Part 9 [Endpoint-2]
  2. 2018.12.11 AWS - VPC : Part 8 [Endpoint-1] (2)
  3. 2017.12.29 Cisco ACI - Design Part 1 (2)

Today Keys : VPC, AWS, Endpoint, Gateway, Interface, services, cloud, 아마존, public


이번 포스팅은 지난 포스팅에 이어서 VPC Endpoint에 대해서 알아봅니다.

VPC Endpoint 중에서 Interface 타입의 Endpoint를 생성해서 어떻게 Endpoint를 이용해서

서비스를 접근 할 수 있는지를 알아 볼 수 있는 간단한 예제 포스팅입니다.

* 관련 포스팅 : VPC Endpoint 알아보기

                        Gateway Endpoint 만들어보기 - 포스팅 준비 중
                       
 


이번 포스팅에서는 Interface 타입의 Endpoint인 CloudFormation을 생성해 보겠습니다.

먼저 Endpoint를 생성하기 위해서 '엔드포인트 생성' 메뉴를 선택하여 Endpoint를 만드는 메뉴로 들어갑니다.

 

EndPoint를 만들 때에는 서비스 유형에 따라서 Interface로 만들지 Gateway로 만들지 다음과 같이 나옵니다.

각 서비스 별로 유형이 정해져 있는 것이며, 서비스를 Interface 혹은 Gateway 유형을 선택하는 것은 아닙니다.

 

Endpoint 생성의 전체 메뉴는 다음과 같습니다.

서비스를 고르고, 어느 VPC에 적용할지를 선택하면 해당 VPC의 AZ 정보가 나오고

각 AZ 별로 어떤 Subnet에 생성할지 나옵니다.

그리고 'Private DNS 이름 활성화' 라는 메뉴가 기본적으로 체크되어 있습니다.

이 부분은 아래에서 다시 설명합니다.

보안 그룹은 우선 기본으로 설정합니다.

 

여기까지하면, 손쉽게 Endpoint를 만들 수 있습니다.

 

생성이후, '사용가능' 상태로는 약 1~2분정도 소요 될 수 있습니다.

정상적으로 생성되면 다음과 같이 생성된 Endpoint 정보를 확인 할 수 있습니다.

 

하단의 서브넷 탭을 보면 실제 생성 시에 선택한 AZ 별로 서브넷에 속하는 IP 주소를 갖고 있는 것을 확인 할 수 있습니다.

 

Endpoint를 생성하기 전에는 해당 VPC 내에서 CloudFormation 서비스에 대한 URL을 확인하면

AWS의 리전 내의 공인 IP 주소를 받아오는 것을 확인 할 수 있습니다.

 

하지만, Endpoint 생성 이후에 동일한 URL에 대한 질의를 하면 Endpoint가 갖고 있는 IP 주소를

도메인에 질의에 대한 결과로 받게 되는 것을 확인 할 수 있습니다.

앞에서  'Private DNS 이름 활성화' 을 뒤에서 알아보겠다고 하였는 데, Endpoint 생성 시에

'Private DNS 이름 활성화' 옵션을 활성화하면(default 값이 활성화) 서비스 별 기본 도메인 값을 VPC 내의 Private DNS에

자동으로 등록이 되어서 해당 값을 응답 받을 수 있게 됩니다.

일반 URL이 아닌 별도 URL을 사용하여 접근하고자 할 경우에는 해당 옵션에 대한 체크를 해제하고

별도 도메인으로 Endpoint IP 주소를 관리 할 수도 있습니다.

 

 

Posted by 네떡지기

Today Keys : VPC, AWS, Endpoint, Gateway, Interface, Private, links, services, cloud, 아마존, public


 

 이번 포스팅은 VPC 네트워크에서 AWS 서비스를 AWS 네트워크를 통해서 직접 접근하기 위한 Endpoint에 대해서 알아보는 포스팅입니다. Endpoint는 접근하는 서비스에 따라서 Gateway와 Interface 타입으로 나뉩니다. 이번 포스팅에서는 Endpoint에 대한 간략한 소개를 하고, 다음 포스팅에서는 Endpoint를 생성해서 접근하는 방법에 대해서 알아 볼 예정입니다.

* 관련 포스팅 : Gateway Endpoint 만들어보기 - 포스팅 준비 중
                       
 Interface Endpoint 만들어보기


 VPC Endpoints

Endpoints

  ▪ VPC 네트워크 내에서 VPC 외부에 위치한 Public한 서비스를 IGW를 거치지 않고 VPC내부에서 직접 접근하도록 지원
  ▪ VPC의 내부의 인스턴스가 AWS 서비스와 통신하기 위해 공인 IP를 가지지 않아도 됨.
  ▪ Endpoint는 Gateway 타입 Interface 타입 으로 구분
  ▪ Endpoint는 VPC에서 접근하고자 하는 AWS Public 서비스 별로 개별 생성하며, Gateway타입 지원하는 서비스와
    인터페이스 타입을 지원하는 서비스가 나누어져 있음. 
       - 타입 별 지원 서비시는 아래에 참고
  ▪ VPC와 AWS 서비스 사이의 트래픽이 AWS 네트워크에서 처리하며, IAM 정책을 사용하여 액세스 제어 가능.


Gateway Endpoint 
  ▪ Endpoint가 Gateway 타입으로 지원하여 AWS 서비스 접근 시, 라우팅으로 접근
  ▪ 라우팅 테이블에서 S3나 DynamoDB의 목적지 네트워크에 대한 Target(Next Hop)으로 Gateway Endpoint를 지정
  ▪ S3와 DynamoDB 접근을 지원


Interface Endpoint
  ▪ Endpoint가 AZ 내의 Elastic Network Interface(ENI)로 생성하고, 해당 서비스에 대한 도메인 Lookup을 해당 ENI 응답
  ▪ Kinesis, Service Catalog, Amazon EC2, EC2 Systems Manager(SSM), Elastic Load Balancing(ELB) API 등을 지원
  ▪ Interface Endpoint 생성 시에는 어느 VPC의 어떤 AZ의 어떤 Subnet을 사용할지 선택
  ▪ Interface Endpoint 는 생성 시에 지정한
 각 서브넷의 IP를 각각 할당 받음.
  ▪ Interface Endpoint 를 이용해서 서비스를 호출하는 경우에는, AWS에서 기본으로 사용하는 도메인을 사용하거나, 
    별도의 서비스 도메인을 지정하여 VPC 내에서 서비스 도메인 Lookup 시에  Interface Endpoint 의  IP로 응답하여
    접근하도록 할 수 있음.
  ▪ 기존에 AWS Public 서비스를 사용하도록 어플리케이션이 만들어진 경우에 기본 도메인으로 Interface Endpoint 
   사용하게 되면  어플리케이션에서 AWS 서비스 호출 시에 별도의 변경 과정없이 Endpoint를 이용한 서비시 호출이 가능.

  

Endpoint 타입별 지원 서비스
  ▪ Gateway
    - Amazon S3
    - DynamoDB
 
  ▪ Interface
    - Amazon API Gateway
    - AWS CloudFormation
    - Amazon CloudWatch
    - Amazon CloudWatch Events
    - Amazon CloudWatch Logs
    - AWS CodeBuild
    - AWS Config
    - Amazon EC2 API
    - Elastic Load Balancing API
    - AWS Key Management Service
    - Amazon Kinesis Data Streams
    - Amazon SageMaker and Amazon SageMaker Runtime
    - Amazon SageMaker Notebook Instance
    - AWS Secrets Manager
    - AWS Security Token Service
    - AWS Service Catalog
    - Amazon SNS
    - AWS Systems Manager
    - Endpoint services hosted by other AWS accounts
    - Supported AWS Marketplace partner services

 

 

 

 

 

Posted by 네떡지기

 

정말 정말 오랜만에 남기는 포스팅입니다.

이번 포스팅은 Cisco ACI와 관련된 디자인 관련과 해당 디자인과 관련된 Bug Report를 포함한 내용을 정리해보았습니다.

올 한해 너무 많은 일들이 벌어져서 포스팅을 못하고 있다가, 몇 가지 이슈로 인해서 다시 정리를 하면서 공유하고자 합니다.


ACI Design Guide


ACI에서 ACI 외부 네트워크와 연결하기 위한 디자인 구성은 다음의 3가지 구성으로 볼 수 있음. 

  ○ Computing과 Border Leaf의 용도로 함께 사용. 이 구성의 경우 해당 Leaf은 endpoint와 WAN 혹은 라우터와 같은 L3 장비 연결

  ○ Border Leaf 전용으로 구성. 이 구성의 경우에는 해당 Leaf은 서버가 연결되지 않고 오직 WAN 혹은 라우터와 같은 L3 장비 연결

  ○ Border Leaf 대신에 Spine을 통한 L3 EVPN 서비스 사용

         - Layer 3 EVPN Services for Fabric WAN은 Cisco ACI GOLF로 명칭 변경 

 

ACI GOLF는 초기의 Spine-Leaf 구조의 Border Leaf을 통한 외부 통신과는 달리 추후에 디자인 된 기능이기 때문에 보다 일반적인 Border Leaf을

사용한 디자인과 관련하여 몇 가지 알아보겠습니다.

 

ACI Release 2.3 디자인 가이드에 Border Leaf 디자인에 대한 고려해야 할 사항에 대한 내용이 추가되어 있습니다.

기존 ACI Release 2.0 디자인 가이드 에서는

 Border Leaf를 L3 Out을 사용한 순수 Border 역할을 하는 경우에는 VRF의 Policy control enforcement Direction ingress를 하도록 권고하며,

 Border Leaf를 Border 역할과 Computing leaf 역할을 함께 하는 경우에는 VRF의 Policy control enforcement DirectionEgress로 권고합니다.

* 단, Nexus 9300 EX Leaf의 경우에는 어떤 경우든 ingress 를 권고

 

Policy Control Enforcement Direction옵션은 VRF 내에 설정된 모든 L3Outs에 VRF 레벨로 적용되며, Ingress가 권고사항임.  

1.2(1)에서 도입되었으며, 1.2(1) 이후의 VRF 생성 시에 기본 값으로 Ingress로 설정됨

 

이후, ACI Release 2.3 디자인 가이드 에서는 보다 세부적인 Border Leaf 디자인에 대한 고려사항이 기술되어 있습니다.

그 중에 일부를 살펴보면 다음의 내용이 있습니다.

모든 Leaf 스위치가 Nexus 9300-EX 혹은 9300-FX 플랫폼인 경우에는 Border Leaf에 EndPoint가 연결되어 있어도 무관합니다.

Computing 스위치에 1세대 Leaf 스위치가 있는 경우에는 다음의 2가지 옵션을 선택해야 합니다.

    - ACI Release 2.2(2e) 혹은 그 이후 버전을 사용한 상태에서 Border Leaf 스위치가 EndPoint 학습을 비활성화 하도록 옵션을 설정해야 합니다.

      이 옵션은 Fabric > Access Policies > Global Policies > Fabric Wide Setting Policy 에서 Disable Remote EP Learn을 선택 합니다.

     - 다른 하나는 ACI 2.0 디자인 가이드와 동일하게 Policy control enforcement DirectionEgress 을 선택합니다.

※가이드 문서에 따르면, 9300-EX / 9300-FX 플랫폼의 경우에 Border Leaf에 End Point가 연결되어도 무관하다고 되어 있으나, 1세대 스위치의 첫 번째 옵션과 동일하게 Disable Remote EP Learn을 설정하도록 되어 있습니다. 이 부분에서는 별도의 OS Release가 나와있지 않기 때문에 추가로 확인이 필요할 듯 싶습니다.

※ ACI 1세대 Leaf 스위치

 - Nexus 9332PQ / 9372PX-E / 9372TX-E / 9372PX / 9372TX / 9396PX / 9396TX / 93120TX / 93128TX

 

이 디자인 가이드는  ACI Bug Report(CSCUz19695) 와 관련된 부분이었습니다.

해당 Bug Report는 VM의 vmotion 시의 트래픽이 끊길 수 있다는 내용인 데,

실제 VM의 vmotion이 아닌 유사 동작인 경우에도 이러한 트래픽 유실이 발생할 수 있을 것으로 보입니다.

결국 EndPoint가 특정 leaf에서 다른 leaf으로 이동되는 EP Move 상황인 경우에 

Border 역할을 하는(실제 L3 Out이 설정되어 있는 leaf이 Border Leaf처럼 동작)에서는 정상적으로 갱신되지 않으면서,

기존 Border가 해당 원격 EP와 통신하기 위한 Tunnel 정보를 그대로 유지하고 있다가 통신이 끊기는 경우입니다.

 

 이 경우에 초기에는 정상적으로 동작을 하지만, 약 10여분 후에 통신이 끊기게 되는 데, 다음과 같은 이유로 보입니다.

1.  Computing Leaf의 EndPoint와 Border Leaf의 EndPoint가 통신을 하면서 서로 간의 통신 Flow입니다.

     모두 Spine을 거쳐가는 Tunnel Interface를 통해서 통신하게 됩니다. 여기서 각 leaf 하단의 EndPoint는 Local로 인식을 하게 되고,

     해당 EndPoint의  Interface 또한 물리 Eth입니다. 

 

2. Leaf#1의 EndPoint가 Leaf#2로 이동 후에 Leaf#1에서 SVR#1이라는 EndPoint는 Local이 아닌 Bounce 상태가 되고, Interface는 Leaf#2로 던지는 Tunnel이 됩니다.

 

3. Bounce Entry aging(Default 630초)이 지난 후에 Leaf#1에서의 Leaf#2를 향한 Tunnel 인터페이스 정보가 삭제되었으나, Border쪽은 정상적으로 EndPoint 정보가 남아있게 되면서, ACI Fabric 이외의 구간에서 SVR#1과 통신이 불가한 상태가 발생하게 됩니다. (Border를 지나치지 않는 경우는 통신 가능)

 

이러한 이슈를 예방하기 위해서 Border Leaf에서 별도로 원격지 EndPoint의 대한 정보를 학습하지 않도록 하고, 

Spine을 통해서 EndPoint 정보를 찾아갈 수 있도록 권고하고 있습니다.

이러한 권고는 ACI Release 2.3 디자인 가이드 문서를 포함하여 다양한 ACI 관련 시스코 문서에 제시되고 있습니다.

실제 원천적으로 앞서 얘기한 방법을 통해 해결 할 수도 있지만, 해당 문제가 발생할 경우에 임시적으로 Border 장비에서 별도의 커맨드를 통해서 EndPoint 정보를 삭제할 수 도 있습니다. (Ex. vsh -c "clear system internal epm endpoint key vrf Tenant:VRF ip ip_Address")

 Bug Report에도 동일하게 명시되어 있지만, 이러한 Bug 동작 1세대 Nexus 9000시리즈에서만 발생하고 있습니다.

 

정리해서 보면...

Border Leaf은 Border로만 사용하고 Computing Leaf 역할로 사용하지 않거나..

Computing Leaf 역할을 함께 사용하게 된다면, 2.2(2e)에서의 Disable Remote EP Learn 옵션을 사용하거나,

전 Leaf을 2세대 이상으로 구성을 하는 방법으로 가야하지 않을까 싶습니다.

관련 Bug Report로 인한 내용은 Cisco 포럼에서 보면, 상당히 많이 처리된 점과 2.2(2e) 이후에 별도의 옵션이 만들어진 점

그리고 2.3 디자인 가이드를 비롯하여 상당 수의 문서에 동일 내용이 있는 것으로 보아 해당 이슈가 잠재되어 있는 사용자 분들이

적은 수는 아니리라 개인적으로 추정해봅니다.

 

마지막으로..

본 내용에 포스팅 내용에 있는 부분들과 관련해서 LST, GST과 같은 테이블에 대한 학습과 Aging, EP Move 등의 사전 내용들을 이해해야만

위와 같은 이슈에 대해서 좀 더 이해할 수 있을 것 같습니다.

관련 내용들은 올해 차례대로 포스팅을 해보고자 했으나, 1년여간 생각치도 못한 일정 등으로 인해서 미뤄두고 있었습니다.

내년에는 그간 미뤄두었던 포스팅을 좀 더 해서, 조금이나마 여러분들께 공유할 수 있도록 하겠습니다.


Posted by 네떡지기

티스토리 툴바