Today Keys :Endpoint, Service, 엔드포인트, 서비스, Private Link, VPC, AWS, cloud, 아마존, Amazon, NLB, ELB


이번 포스팅은 VPC Endpoint Service를 생성하고, 생성한 Endpoint Service를 Endpoint(Private link)로

생성해서 직접 사용해보는 2번째 예제입니다. 1번째에서는 NLB를 '인터넷 연결'용으로 생성하였고,

이번 포스팅에서는 '내부'용으로 생성해서 Endpoint Service를 연결합니다.

본 예제에서 다뤄지는 최종 그림은 다음과 같습니다.

 

 

※ 설명에 필요한 컴포넌트만 넣었으면, 전체 컴포넌트가 표기되진 않았습니다.

관련 포스팅 : AWS - VPC : Part 12 [Endpoint-4]

                    AWS - VPC : Part 11 [Endpoint-3] 

                    AWS - VPC : Part 9 [Endpoint-2]  

                    AWS - VPC : Part 8 [Endpoint-1]  


Endpoint Service는 Endpoint-3 포스팅에서 언급된 것처럼 앞단에 NLB(Network Load Balancer를 구성해야 합니다 .

NLB 구성은 다음과 같이 '인터넷 연결'과 '내부' 용으로 나뉘는 데,  

Endpoint-4 포스팅에서는 '인터넷 연결'로 생성한 로드밸런서로 Endpoint Service를 만들었었고

이번 Endpoint-5에서 '내부'로 생성한 로드밸런서로 Endpoint Service로 만들겠습니다.    

 

 

  '내부'용으로 ELB를 다음과 같이 생성 하였습니다.  

 

 

  ELB로 생성된 도메인을 질의해보면, 다음과 같이 사설 Subnet IP를 갖고 있는 인스턴스가 반환됩니다.  

 

  ELB를 생성하지 않은 다른 VPC의 인스턴스에서도 ELB 도메인에 대한 질의를 확인해봅니다.

 

  물론 사설이기 때문에 정상적으로 서비스가 되지는 않습니다. 

(VPC Peering을 맺는다면 또 다른 얘기겠지만... )

 

  이제 Endpoint Service를 생성합니다.

사설로 만든 ELB(NLB)를 연결합니다.

 

 

  정상적으로 Endpoint Service가 만들어진 것을 확인 할 수 있습니다.  

 

   생성된 Endpoint Service의 '서비스 이름'을 확인합니다.

 

 

  이제 Endpoint Service를 사용 할 엔드포인트를 생성합니다.

이름으로 서비스 찾기에서 방금 전에 만든 Endpoint Service의 '서비스 이름'을 입력하면 서비스를 찾을 수 있습니다.  

 

Endpoint가 정상적으로 만들어시고 상태도 '사용 가능'으로 되면, 

Endpoint의 DNS 이름을 확인합니다.  

  

 

 Endpoint의 DNS 이름을 확인해보면, 다음과 같이 Endpoint를 생성한 AZ의 서브넷 IP로 할당이 됩니다.     

 

 서비스 호출도 Endpoint(Private Link)를 통해서 이제 정상적으로 되는 것을 확인할 수 있습니다. 

 

 경로를 확인하면 바로 직접 연결된 Endpoint(Private Link)로 끝나게 됩니다. 

 

 앞서 AWS 서비스로 Endpoint를 만들 때도 확인했던 부분이지만,

Interface Endpoint 유형의 IP 주소는 Endpoint의 '서브넷' 탭을 보면 어느 AZ에 속한 것인지 확인 할 수 있습니다.  

 

 

 

 

 

 

Posted by 네떡지기

Today Keys :Endpoint, Service, 엔드포인트, 서비스, Private Link, VPC, AWS, cloud, 아마존, Amazon, NLB, ELB


이번 포스팅은 VPC Endpoint Service를 생성하고, 생성한 Endpoint Service를 Endpoint(Private link)로

생성해서 직접 사용해보는 예제입니다.

 본 에제에서 다뤄지는 최종 그림은 다음과 같습니다.

※ 설명에 필요한 컴포넌트만 넣었으면, 전체 컴포넌트가 표기되진 않았습니다.

관련 포스팅 : AWS - VPC : Part 11 [Endpoint-3] 

                    AWS - VPC : Part 9 [Endpoint-2]  

                    AWS - VPC : Part 8 [Endpoint-1]  


 

Endpoint Service는 Endpoint-3 포스팅에서 언급된 것처럼 앞단에 NLB(Network Load Balancer를 구성해야 합니다 .

NLB 구성은 다음과 같이 '인터넷 연결'과 '내부' 용으로 나뉘는 데,  

Endpoint-4 포스팅에서는 '인터넷 연결'로 생성한 로드밸런서로 Endpoint Service를 만들고

Endpoint-5에서 '내부'로 생성한 로드밸런서로 Endpoint Service를 각각 만들 것입니다.

(실제 Endpoint Service를 만드는 데는 차이는 없긴합니다.)

 

 NLB를 다음과 같이 생성해 놓았습니다.

서로 다른 AZ에 1개씩 Instance를 생성하였고, 80 서비스를 각각 올려두었습니다.

 

  구성도로 보면 다음과 같습니다.

 

   제 로컬 PC에서 ELB에 대한 도메인을 확인해보면, ELB에 할당된 인스턴스의 EIP로 응답하는 것을 볼 수 있습니다.

앞서 NLB를 생성 할 때. '인터넷 연결'용으로 만들었기 때문에 NLB 생성 시에 할당한 EIP로 응답합니다.

 

 

  AWS의  ELB를 생성한 VPC가 아닌 다른 VPC이 인스턴스에서 확인을 해도 동일하게 보입니다.  

정상적으로 서비스가 되는지 보기 위해서 curl로 확인해보니

제가 설정한 'ZIGISPACE - SVR#1'과 'ZIGISPACE - SVR#2' 라는 값이 정상적으로 보입니다.

 

  다음은 다른 VPC의 인스턴스에서 Traceroute에 대한 값입니다.

실제 통신이 IGW를 통해서 공인 IP로 통신합니다. 

 

  이제 본격적으로 Endpoint Service를 만듭니다.

NLB를 생성한 곳에서 Endpoint Service를 생성합니다.  

 

   Endpoint Service 생성 시에는 어떤 NLB로 연결할지 고르게 되어 있습니다.

앞서 만든 'ZIGI-ELB-Pub'로 선택합니다.

아래 옵션 중에 '엔드포인트 연결 수락 필수'가 기본적으로 체크되어 있습니다.

여기서는 체크되어 있다는 것만 인지하고 뒤에서 보겠습니다..

 

  서비스 생성 버튼을 누르면 다음과 같이 Endpoint Service 생성이 완료됩니다. 

 

  생성이 완료된 안내창과 생성 후 세부정보를 보면 Endpoint Service의 DNS 이름이 있습니다.

이제 이 이름으로 Endpoint를 생성 할 수 있습니다.  

 

 

  이제 Endpoint를 만들겠습니다. 

 

 

  Endpoint를 생성할 때, 예전 포스팅에서는 기본 AWS 서비스로 Endpoint를 만들었다면, 

이번에는 '이름으로 서비스 찾기'를 합니다.

그리고 서비스 이름에 앞서 만든 Endpoint Service의 DNS이름을 선택하면 해당 서비스를 찾을 수 있습니다.

Endpint를 만들 VPC와 사용 영역별로 서브넷을 지정합니다.

하나의 가용 영역에 하나의 서브넷만 지정이 가능합니다.  

 

 

'엔드포인트 생성' 버튼을 누르면 다음과 같이 Endpoint를 만들어 지는 데,

바로 사용 할 수 있는 것이 아니라, '수락 대기 중' 상태로 뜹니다.

앞서 Endpoint Service를 만들 때 '엔드포인트 연결 수락 필수'가 체크되어 있기 때문입니다.

만약 체크를 해제하면 바로 사용할 수 있지만, 그게    아니라면 이렇게 수락이 필요합니다.

 

  Endpoint Service 쪽에서 보면 '엔드포인트 연결' 탭에 수락대기 중인 Endpoint가 확인됩니다.  

      

 

  해당 Endpoint를 선택해서 요청을 수락하면, 

 

   이렇게 다시 한 번 요청을 수락할 것인지 묻는 데, 수락을 합니다.

 

 

 Endpoint가 사용이 가능한 상태로 바뀌게 됩니다.   

 

  이제 Endpoint를 만든 VPC에서 Endpoint 도메인으로 질의를 하면,

Endpoint 생성 시에 지정한 VPC의 서브넷으로 Endpoint가 만들어집니다.

 

 

Endpoint로 서비스를 호출하면 정상적으로 서비스가 호출되는 것을 확인 할 수 있습니다. 

 

  실제 Trace를 직어보면 바로 Endpoint로 만들어진 VPC 내의 서브넷을 호출하고 정상적으로 완료되는 것을 볼 수 있습니다.  

 

 

 

 

Posted by 네떡지기

이번 포스팅은 ACI Bug Report 관련 내용입니다.

 

지난 포스팅(http://zigispace.net/957) 에 이어서, ACI OS Upgrade 중에 발생할 수 있는 Bug Report(CSCvb94260)입니다.

2.1미만의 버전에서 발생할 수 있다고 하기 때문에 2.1이상의 버전에서 더 상위 버전으로의 Upgrade에는 발생하지 않을 수 있습니다.

 

이 버그에 대한 증상은

 1. APIC 업그레이드 중에 먼저 진행된 APIC은 정상적으로 Upgrade가 완료되었으나, 이후에 업그레이드 되는 APIC의 상태가 75%에서 멈춰있게 됩니다.  이 경우 75%에서 멈춰있는 APIC에서 확인 할 때, 정상적으로 완료된 APIC의 정보가 기존 버전으로 표기

 

 2. 모든 APIC이 정상적으로 업그레이드가 되고, fully fit 상태까지 되었으나 각 장비에서 acidiag로 확인 시에는 local APIC에 대한 버전만 최신 버전이고 다른 APIC은 기존 버전으로 표기

 

상태를 확인해보면, APIC 2번기가 정상적으로 Upgrade된 상태에서 APIC 3번기가 Stuck이 걸려있을 때,

APIC 2번에서는 2번기 상태를 보면 정상적으로 Upgrade가 되어 있고

APIC 3번기에서 2번기를 상태를 보면, 기존 OS이고 time stamp도 정상적으로 업그레이드 된 시간보다 더 이후 시간으로 체크되어 있음.

 

apic2# acidiag avread | egrep "id=2.*version" | cut -d ' ' -f 7-10,20-21
appliance id=2 version=2.2(2k) lm(t):2(2017-07-25T11:24:01.244+10:00)

apic3# acidiag avread | egrep "id=2.*version" | cut -d ' ' -f 7-10,20-21
appliance id=2 version=2.0(2f) lm(t):2(2017-07-25T11:40:02.248+10:00)

 

2.1 이상에서는 해당 버그가 없기 때문에 2.1 미만의 버전에서만 발생합니다.

 

해당 버그가 발현될 경우에는

위의 예의 APIC 3에서 APIC 2의 정보를 정상적으로 가져오지 못한 상태가 되는 데,

APIC 2에서 "acidiag restart mgmt"를 통해서 APIC에 서비스를 재기동하면

APIC 3에서 APIC 2에 대한 정보가 업데이트 되면서, 정상적으로 Upgrade를 진행 할 수 있습니다.

 

 

 

Posted by 네떡지기
분류없음2016.01.15 07:47

Today Key : Cloud Native App, CNA, Microsoft, Service, MSA, Immutable Infrastructure

 

어제 프레젠테이션용 CNA 포스팅에 이어서, 오늘은 기존의 형식의 CNA 포스팅입니다.

큰 줄기는 당연히 이번 포스팅 내용을 기준으로 만든 프레젠테이션 자료였기 떄문에 똑같지만

아주 약간 추가되어 있는 내용이라고 보시면 될 것 같습니다. 

혹시 수정이나 추가되었으면 하는 부분은 알려주시면 감사하겠습니다.


 

Cloud Native App 개요

Native App

   - 특정 플랫폼이나 Device에서 사용되도록 개발된 Application.

      최적화 환경에서 구동되기 때문에 성능적으로 Web App 비해 우수.

Web App [ Native App ]

   - 일반적인 표준 Web 기술을 사용하여  Platform이나 Device에 상관 없이 사용되도록 개발된 Application.

      표준 기술로 구현하기 때문에 멀티플랫폼, 플랫폼에 대한 이식성이 우수

 

Cloud Native

  - 클라우드 환경에 최적화 됨, 혹은 태생이 클라우드인, 클라우드 전용

 

Cloud Native App

   - 클라우드 환경에 최적화되어 서비스 되도록 개발된 Application

    - Native App이라는 명칭을 쓰지만, Cloud 환경 어디에서든 구동되기 때문에 의미상으로는 Web-App 같음.

   

 

Cloud Native App 특징

Scalable

    - 유연한 서비스 확장이 가능 (별도의 아키텍처를 변경이 없이)

    - 서비스에 대한 일시적인 확장 수요에 따라서 빠른 서비스 확장 축소가 가능

Agility

    - Application 배포 업데이트 등을 빠르게 구현 가능

    - 빠른 배포 업데이트를 위해 서비스는 독립된 하나의 작은 형태로 동작

Continuity

    - 서비스가 지속적 배포되고, 관리될 있도록 .

    - 서비스에 대한 업데이트 시에도 기존 서비스를 즉각적으로 대체 가능. (서비스 연속성)

    - 서비스 배포를 빠르고, 쉽게 구현하여 지속적인 서비스의 배포(업데이트, 오류 수정 등의 이슈) 가능.

Automation

    - 자동화를 통해서 서비스에 대한 확장 축소가 가능.

    - Applicaion 구동되기 위한 플랫폼을 손쉽게 자동으로 구축이 가능

 

 

 

 

 

Cloud Native App 이해하기 위한 특징

The twelve-factor app

서비스로 제공되는 Web-App, 혹은 SaaS(Software As A Service) 불리는 최근의 소프트웨어를 개발하기에 적합한 방법론

 

12 Factor App 더보기

 

 

Micro Service

독립적이고 매우 작은 개별 서비스들로 전체의 서비스를 구성

서비스는 다른 서비스와의 종속성을 없애며, 하나의 서비스로 구성된 Application 비해서 가벼움.

 

http://zigispace.net/884

 

Standard API

REST-API와 같은 표준화 된 방식의 API 사용하여 서비스 간의 통신

표준화 통신 방식을 사용하기 때문에, 서비스의 구현은 Polyglot Programming 같이 다양한 방향으로

  구현이 가능. (서비스 간에 통신이 특정 방식이 아니라, 표준화 되어 있기 때문)

http://zigispace.net/891

 

Immutable Infrastructure

Develoment ,QA ,Deploy 전반에 걸쳐서 항상 동일한 환경의 인프라를 제공

Provisioning Tool 혹은 특정 Script 등의 형태 등을 통해서 동적으로 동일한 인프라 환경을 빠르게 제공 가능

  , 하나의 인프라를 구축 후에 지속적인 관리 형태 방식 이외의, 동일한 인프라를 새로 만들어서 기존 인프라를 쓰고

  버릴 있는(disposable) 형태 가져갈 있음

 

Container

단일 Host의 Resource를 격리하여 다수의 시스템을 운영하게 하는 OS 레벨의 가상화

Host OS Resource 공유해서 사용하기 때문에 매우 가벼움.

특히 Docker 같은 Container 형태에서는 이미지가 Layered 형태로 관리되기 때문에 이미지 자체가 가벼움

결국 Resource 대한 효율성 가벼운 형태이기 때문에 Application 배포에 유리

 

Self-Service Infrastructure
Infrastructure-as-a-Service

구조화 된 인프라 형태를 빠르게 배포 가능

IAC (Infrastructure as Code) 코드를 실행하는 것으로 인프라 구축이 가능

 

Posted by 네떡지기
분류없음2016.01.14 13:12

Today Key : Cloud Native App, CNA, Microsoft, Service, MSA, Immutable Infrastructure

 

이번 포스팅은 Cloud Native App에 관한 포스팅입니다.

이 포스팅은 2번에 걸쳐서 나눠서 올려지며, 이번에는 간단한 발표용으로 만든 프레젠테이션 이미지를 포스팅하며

이번 주말 전까지는 일반 포스팅 형식으로 같은 내용을 포스팅 할 예정입니다.

본 자료는 슬라이스쉐어로도 업로드되어 있으니, 다운로드는 아래 링크에서 받으시면 됩니다.
( 슬라이드쉐어 : http://www.slideshare.net/ssuserc08d76/cloud-native-app )


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Posted by 네떡지기
분류없음2015.02.15 17:42

 

Nexus Ping Drop 관련 이슈가 예전에  있어서 확인하고 조치하였다가,

네전따 카페에서 다른 분이 동일한 증상이 있어서, 알려드렸었는데 오늘 문득 또 다른 분이

쪽지로 물어오신 김에 아주 짧고 간단하게 정리하고 넘어가봅니다. (그 분도 이 증상이 맞는지 모르겠네요..)

 

Nexus 장비에서 간헐적으로 Ping Loss가 발생하는 경우가 있었습니다.

(짧게 정리할 것이기 때문에 각설하고 바로 결론..)

Nexus 7K에서는 Control Plane을 보호하기 위해서 CoPP(Control Plane Policing)이 기본적으로 활성화 되어 있습니다.

아래와 같이 내용을 확인할 수 있으며,

 

NX-OS# show run copp
<snip>
control-plane
   service-policy input copp-system-policy

 

해당 설정을 제거하고, 다시 Ping을 해보면 정상적으로 Ping이 나가는 것을 볼 수 있습니다.

 


※ 관련 링크
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/4_1/nx-os/security/configuration/guide/sec_nx-os-cfg/sec_cppolicing.html#wp1082584

 

 

https://supportforums.cisco.com/document/59621/icmpping-drops-when-pinging-nexus-7000?utm_source=twitterfeed&utm_medium=twitter

 

http://www.cisco.com/c/en/us/support/docs/switches/nexus-7000-series-switches/116043-copp-nexus7000-tshoot-00.html

 

http://www.cisco.com/c/en/us/support/docs/switches/nexus-7000-series-switches/116043-copp-nexus7000-tshoot-00.html#anc5

 

 

 

Posted by 네떡지기
분류없음2014.12.15 22:53

Python for Networker 13번째는 본래 의도와는 다르게 다시 조금 쉬어가는 포스팅입니다.

OnePK의 예제 코드를 다뤄보기 전의 Cisco OnePK에 대해서 조금 더 간단히 알아보는 내용입니다.

다음 포스팅부터 이제 실제 예제코드는 함께 다뤄질 예정입니다! ^^

또한 본 포스팅은 OnePK에 대한 소개이기 때문에 이론적인 부분에 있어서는 지속적으로 업데이트 할 예정입니다.

 


 

OnePK Introduce

   - 다양한 Cisco Device를 OnePK라는 Application Toolkit을 통해 기존 네트워크를 programmability하게 사용 가능하도록 함.

 

 

 

 

 - 기존 IOS ,OSd/XE, XR, NX-OS 모두 각각  onePK API를 지원하는 환경에서 다양한 언어(C, Java, Python)로 만들어진

   API를 통해서 통신하여 동작할 수 있도록 함.

 

 

 

 

 

OnePK Service Set

  

 

 

○ OnePK Hosting Option

     - OnePK는 아래와 같은 3가지 방식으로 동작할 수 있도록 지원 됨.

    ▷ Process Hosting

        - OnePK가 동작하기 위한 Module 형식의 Software 구조가 필요로 함. 

        - Latency와 Delay 매주 작음.

        - 해당 장비 내부에서 동작하기 때문에 자원을 공유함.

 

    ▷ Blade Hosting

        - OnePK가 동작하기 위한 Blade Hardware가 필요로 함.

        - Latency와 Delay가 비교적 작음.

        - 모든 Platform을 지원

 

    ▷ End-Poin(Node) Hosting

        - 별도의 Device를 사용

        - Latency와 Delay가 비교적 큼.

        - 모든 Platform을 지원

  

  

 

 

 

 

 

OnePK 지원 장비 

  

 - 현재 OnePK는 1.3 Version이며, 아래의 Hardware와 Software Version에서 동작한다. (2014년 8월 기준)

Device

Software

Cisco ASR 1000 & ISR 4400 Series Router

CSR 1000V Cloud Services Router

Cisco IOS XE 3.12.0S

Cisco ASR 9000 Series Aggregation Services Router

Cisco IOS XR 5.2.0

Cisco ISR G2

Cisco IOS Release 15.4(2)T

Cisco ME 3600X/24CX

Cisco IOS Release 15.4(3)S

 

 

 

OnePK Platform별 지원 Service Set 

 

 Service Set

ME3600X/24CX

ISR G2 

ISR 4400 

ASR 1000 

ASR 9000 

CSR 1000V 

Data Path 

 

Policy

Routing 

Element

Discovery

Utility

Developer

Location

 

 

 

MediaTrace
(PathTrace)

 

 

Identity

(SANET)

 

 

 

 

 

 

 

○ Language별 OnePK Service Set 지원

   - C언어는 모든 Service Set 지원

   - Java, Python은 Data Path를 제외한 모든 Service Set 지원

 

 

 

Posted by 네떡지기

티스토리 툴바