'Plane'에 해당되는 글 2건

  1. 2016.04.02 DUCP (Docker Universal Control Plane) - Part 1
  2. 2014.09.29 Nexus : NX-OS Part33(OTV 6 - DataPlane)
분류없음2016.04.02 23:11

Today Key : DUCP, UCP, Docker, Universal, Control, Plane, 도커, 클러스터, CaaS

 

이번 포스팅은 Docker의 Enterprise의 On-Promise 솔루션인 DUCP에 대한 첫 번째 포스팅입니다.

UCP의 첫 번째 포스팅에서는 UCP에 대한 간략한 소개 내용과 Controller 노드의 설치에 대한 내용입니다.

이어질 UCP 포스팅에서는 Controller Node 이외의 설치 및 기능에 대해서 알아 볼 예정입니다..

 


 

 

 

DUCP (Docker Universal Control Plane)
  

  ▪ Enterprise 의 On-Promise 솔루션
  ▪ Production 환경에서 UCP를 사용하여 Docekrized Application들을 배포하고 관리  가능
  ▪ Agaility & Portability 제공
  ▪ Provision, Cluster Docker Host, Resource에 디자인 된 Docker Native 솔루션
  ▪ Docker API를 모두 지원

 


UCP 아키텍처

Docker UCP는 다수의 노드로 구성된 클러스터로, 각 노드는 Commercially Supported (CS) Docker Engine이 설치
클러스터를 구성하는 노드는 다음의 3개의 노드로 구분할 수 있음.


  ▪ UCP controller node
      사용자의 요청을 받아서 UCP Node를 제어하는 역할


  ▪ UCP replica nodes
      Controller의 High-availability를 위한 Node


  ▪ UCP nodes
       Container가 실제 실행될 노드
 

  

 

UCP 요건

  ▪ 하드웨어 및 소프트웨어
      - 1.50 GB 메모리
      - 3.00 GB 이상의 여유 디스크 용량
      - 다음과 같은 OS 버전 설치
           RHEL 7.0, 7.1
           Ubuntu 14.04 LTS
           CentOS 7.1
           Kernel version 3.10 or higher
      - CS Docker Engine
           ※ CS Engine :  Commercially Supported Docker Engine  

 

  ▪ 서비스 포트

      - UCP 서비스를 위하여 다음과 같은 서비스 포트를 사용

 

 

 

 

  ▪ Subject alternative names (SANs)
       - UCP에서 각 노드 간의 통신은 Mutual TLS로 보호되며, TCL 설정은 UCP 설치

       - 이를 위해, UCP의 모든 클라이언트는 UCP Swarm Root CA에 서명된 Swarm TLS Certificate 체인을 사용

       - Ceritificate system 제공하기 위해 SAN을 사용

       - 즉, UCP Node간의 통신 보호를 위한 시스템을 위해서 사용

  ▪ IP address & FQDN 설정
      - UCP install 명령은 FQDN을 사용하여 Host를 찾음.
      - FQDN이 설정되지 않은 경우에는 설치 시에 Host 주소를 입력하라는 메시지가 표시
      - 설치 시에 --host-address  옵션 사용 가능
      - AWS, Digital  Ocean같은 클라우드 환경에서 설치 시에 Private IP를 할당 받게 되는 경우에는 모든 node간의 통신이 되어야

        UCP 동작이 가능

  ▪ Data volumes
      - UCP는 데이터 유지를 위해서 특정 볼륨을 사용하기 때문에 Production을 위한 UCP 설치 시에는 다음과 같은 볼륨을 생성

  


      - 만약 이러한 볼륨 생성하지 않은 경우, ucp install 시에 default volume driver/flags를 사용하여 만들어짐.

 

 

 


 

 

 

UCP 설치 단계 [Controller 설치까지]

UCP를 테스트하기 위한 설치 방법으로 Windows나 MAC에서  boot2docker를 사용하여 설치하는 방법과 Production 환경에서의

UCP를 설치하는 방법이 있음.  Production 환경의 설치 중 아래의 6개 단계까지 진행을 하면 Production 환경에서의 UCP Controller Node를 설치할 수 있음.

 

○ 테스트용 설치 링크 : https://docs.docker.com/ucp/evaluation-install/

○ Production 환경에서의 설치

Step 1
  ▪ 필요한 서비스 포트 오픈(방화벽 등)

 

Step 2
  ▪ CS Docker Engine  설치  
        : https://docs.docker.com/docker-trusted-registry/install/install-csengine/

 

Step 3
  ▪ Customize user-named volumes (optional)

 

Step 4
  ▪ Customize the CA used (optional)

 

Step 5
  ▪ Install the UCP controller

Step 6
  ▪ License your installation
         : https://hub.docker.com/


※ 참조 : https://docs.docker.com/ucp/production-install/

 

 


 

 UCP 실행

 

◎ 설치 환경

    - Microsoft Azure

 

 

 

 

 

  ▪ 설치 후, 접속 화면

 

 

 

  ▪ Dashboard

      - 현재 UCP에 대한 정보를 확인할 수 있음.

      - 초기 설치 시에, UCP 구동을 위해서 Controller Node는 7개의 이미지로 7개의 Container가 기본 동작

 

 

 

※ UCP Images

 

 ※ UCP 기본 Container

 

 

 

 

 

  ▪ UCP에서 지원되는 기능들에 대한 메뉴

    - Application, Container 등의 기능을 위한 메뉴가 있음.

 

 

 

 

 

 

 

 

 

 

 

 

 

Posted by 네떡지기
분류없음2014.09.29 21:26

 


오랜만에 포스팅하는 Nexus : NX-OS 시리즈입니다.

 

예전에 포스팅했던, OTV의 Data Plane의 Unicast/Broadcast 부분에 이어서, Multcast에 대한 Data Plane입니다.

휴가 전에 대부분의 내용을 쓰고, 휴가 직전에 포스팅하지 못해서 마지막 부분만 휴가 이후에 올리게 되네요..

무척 오랫만에 올리는 Nexus 정리 포스팅입니다.  ^^;


 

OTV Data Plane – Multicast Traffic

• 특정한 경우에 Remote Site간의 Layer 2 Multicast 통신이 필요한 경우가 있을 수 있다.

• OTV Site 간의 Layer 2 Multicast의 경우에 Multicast가 지원환경과 지원불가 환경으로 나누어서 고려되어야 한다.

 


 

 

OTV Data Plane – Multicast Traffic (Multicast 지원 환경)

• Layer 2 Multicast 트래픽은 OTV overlay를 통해서  전송되며,  Suboptimal한 Head-end 복제를 방지하기 위해

   Multicast가 가능한 Transport Infrastructure가 요구된다.

•Multicast가 가능한 Transport Infrastructure를 통해 Layer 2 Multicast를 전송하는 데 하나의 SSM

  (Source Specific Multicast) Group를 이용한다.

   이 Group은 Site간의 OTV Control Protocol을 전송하기 위한 ASM group과는 독립적으로 사용된다

 

 

 

 Multicast Source 최초 활성화 시

  1. West Side에서 활성화된 Multicast Source가 Group Gs로 Traffic을 전송한다.


   2. Local의 OTV Edge Device는 첫 번째 Multicast Frame을 수신하고, Group Gs와 Transport  Infrastructure에서 사용될 특정
       SSM Gd Group간의 Mapping을 생성한다.


       Layer 2 Multicast Data Stream을 전송하는 데 사용되는 SSM Group의 범위는 Overlay Interface의 설정에 들어가게 된다.

       Ex>  NX-OS(config-if-overlay)# otv data-group 232.1.1.0/28

 

  3. OTV Control Protocol은 모든 Remote OTV Edge Device들의 Gs와 Gd 간의 Mapping을 전달하기 위해 사용된다.
      Mapping 정보는 Multicast Source가 속한 VLAN과 Mapping이 만들어진 OTV Edge Device의 IP address간의 정보로 구성된다.

                                 

 

 

 

 Multicast Source와 동일한 VLAN에 Deploy된 Receiver가 Group Gs에 Join하는 과정

  1.East Side Client가 GS group에 Join 할 수 있도록 IGMP Report를 전송

 

  2.OTV edge device가 IGMP Message를 snoop하고, VLAN A에 속한 Gs Group의 Active receiver이 있음을 확인한다.


  3.OTV Device는 OTV Control Protocol Message를 모든 Remote Edge Device로 전송한다.


  4.West Side의 Remote OTV Edge Device는 GM-Update를 수신하여, OTV Overlay를 통해서 전달될 group Gs에 대한
     OIL(Outgoing Interface List) 를 업데이트 한다.

 

  5.East Side의 OTV Edge Device는 이전에 IP A에 의해서 확인한 West side의 OTV Edge Device로부터 받은 Mapping정보를 찾는다.
      East Edge Device는  (IP A, Gd) SSM Group에 Join하기 위한 IGMPv3 report를 전송한다.

     이를 통해 Transport Infrastructure를 통해서 Multicast Gs를 전송하는데 사용될 수 있는 SSM tree(group Gd)를 만든다.

 

 

 

 

 

 OTV를 통한 Multicast 전송 과정

  1.OTV Edge Device가 Gs Stream를 수신하고, Overlay를 통하여 Gs Group을 수신하고자 하는 Receiver에게 전송하기 위해

    OIL를 확인 후에, Interface를 결정한다.

 

2. Edge device에서 Original Multicast frame을 Encapsulation 한다.  Outer IP header의 Source는 자신의 IP A로 설정되고,

     Destination은 Multicast data를 전송하기 위해 할당된 Gd SSM Group으로 설정된다.

 

3. Multicast Stream Gd는 기존의 Transport Infrastructure를 통해 만들어진 SSM Tree를 통해서, Gs Stream을 수신하고자 하는

     Receiver들이 있는 OTV Remote Site로 전송된다.

 

4. Remote OTV edge Deivce들은 해당 Packet을 수신한다.

 

5. Packet은 De-capsulation 되어서, 각 Site 내의 Receiver들에게 전송된다.

 

 

 

 



OTV Data Plane – Multicast Traffic (Unicast only Transport Infrastructure 환경)

  • Layer 2 Multicast 트래픽은 OTV overlay를 통해서  전송되며,  Suboptimal한 Head-end 복제를 방지하기 위해

      

Unicast Core망을 통한 Multicast Group Gs에 Receiver Join 시

  1. East Site에 있는 Client가 Gs group에 Join하기 위해 IGMP report를 보낸다.

 

  2. OTV Edge Device는 IGMP Message를 확인하여, VLAN 100에서 group Gs에 Active Receiver가 있다는 것을 알게 된다.

 

  3. OTV Edge Device는 OTV control protocol message(GM-Update)를  각 Unicast List에 속해 있는 remote Edge Device로

     전송하여 2번에서 확인된 정보를 전달한다.

 

   4. Remote Edge Device들은 GM-Update Message를 수신하게  되고,  multicast group Gs1의  receiver가  IP B Address로

    확인되는 OTV Device를 통해서 연결되어 있다는 정보와 "Data Group Mapping Table"을 함께 Update 한다.

 

 

 

 

 

 

 Unicast Core망을 통한 Layer 2 Multicast Stream Gs 전송 시

  1. Gs1을 목적지로 하는 Multicast TrafficWest Site의 내부에서 만들어지게 되고, OTV Edge Device“Data Group Mapping Table’에서

      OIFLookup한다. 아래 예시의 ‘Data Group Mapping Table’에서는 해당 Multicast Traffic EastSouthOverlay를 연결된 것을 확인한다.

  2. West SiteOTV Edge Devicehead-end replication을 통해 원래  Layer 2 Multicast Frame을 캡슐화한 2개의 Unicast IP Packet를 생성한다.

      이 때, Outer IP header IPWest SiteIP A로 설정이 되고, Destination IPSouth/EastIPIPB/C로 설정된다.

  3.  Unicast FrameRouting을 통해 Transport Infrastructure를 거쳐서 Remote OTV Device로 전송되게 되어, De-capsulation이 되어

       SiteReceiver들에게 전송된다.  이 때, North Site에는 해당 Multicast TrafficReceiver가 없기 때문에 Data Group Mapping TableNorth Site가 존재하지 않고,  따라서 Frame이 전송되지 않는다.

 

 

 

 

Posted by 네떡지기

티스토리 툴바