'Group'에 해당되는 글 2건

  1. 2017.07.03 Cisco ACI - Part 1 (Interface Policies)
  2. 2016.09.05 Puppet Part 6
네트워크2017.07.03 18:29

Today Keys : ACI, Interface, Policies, Policy, Profile, Group


이번 포스팅은 Cisco ACI 로 시작하는 시리즈 포스팅의 첫 번째 포스팅입니다. 

작년 말부터 Cisco ACI를 운영하기 시작하면서 정리를 조금씩 하면서 포스팅을 준비했는 데.. 

예전부터 그랬지만 항상 포스팅을 하기 위한 준비 작업 시간도 오래 걸리거니와 

또 맘에 들 때까지.. 무작정 기다리기만 하면 포스팅을 하지도 못하고.. 계속 늦춰지기만 하게 되네요. 

우선 짧게 짧게라도 가볍게 정리해 놓은 것들을 풀어보는 포스팅을 하려고 합니다. 


전체적인 흐름과 아키텍처를 잘 짜야만 된다고 생각되는 것이 ACI 이긴 하지만.. 

우선 포스팅은 단편적인 부분부터 시작해봅니다.  그렇지 않으면 무작정 계속 늦어질 듯 싶으니까요..

나중에 흐름과 전체 구조는 하나씩 짜맞춰 나가는 포스팅을 하도록 하겠습니다! ^^


첫 번째 포스팅은 Interface의 설정을 어떻게 할 것인지에 대한 내용입니다.

개별 인터페이스별로 설정을 하는 것이 아니라, 기존의 Port-Profile 기능처럼 인터페이스에 적용할 Profile을 만든 후에 

이를 동일하게 사용되는 전체 인터페이스에 손쉽게(?) 적용할 수 있습니다. 




Interface Policies


Policies 


  - Switch Interface 대한 속성, CDP, STP interface에서 설정한 가능한 Config 대해서 세부 속성.

  - 기 CLI에서의 Interface 명령 안에 선택되는 옵션 수준

              * 설정 가능한 정책


                  - Link Level , CDP, LLDP, Port Channel, STP, Storm Control, Port Security 등


                  

< Interface Policies의 Policies에서 설정할 수 있는 정책 >


< Link Level Policy 설정 >




< CDP 설정 >


Policy Group 


  - Policies 엮어서, 하나의 Interface 설정 값을 만듬.

  - 실질적으로 특정 인터페이스 설정 될 Port Profile 설정

 

  - 일반 Interface 설정은 하나의 Policy Group으로 만들어서 다수의 인터페이스에 적용해서 사용. 

 

  - Policy Group은 일반 Individual Port와 Port-channel, vPC 로 나누어서 설정을 하게 되며, 

    

    Port-Channel과 vPC는 개별로 생성 해야 함. 

 


< Policy Group의 설정 >



< 일반 Individual Interface Policy 설정 >




< Port-Channel Interface Policy 설정 >





<  vPC Interface Policy 설정 >




Profile 


 - Policy Group에서 설정된 인터페이스 설정 값을 적용할 Profile 설정

 

 - Policy Group을 적용할 인터페이스를 지정한다고 생각하면 됨. 이 과정을 Interface Selectors 라는 메뉴에서 지정하게 되며


  여기서는 어떤 Leaf 대한 Interface인지까지는 지정하지 않고, 단순히 Interface ID(Interface 번호) 지정 하게 됨. 


  실제 어떤 Leaf의 적용될지에 대한 mapping 과정은 Switch Policies에서 적용



<  vPC Interface Policy 설정 >



<  vPC Interface Policy 설정 >


Posted by 네떡지기
DevOps/Automation2016.09.05 23:14

 Today Key : Puppet, 퍼펫, Environment, 환경, Manifest, Group, 그룹, Production, conf, automation, 자동화

 

 

새로 쓰는 Puppet 관련 6번째 포스팅입니다.

정리를 해두고, 포스팅 하는 데까지 이래저래 시일이 걸리기도 하고 다른 것들을 보느라,

더뎌지고 있지만.. 앞으로 더 포스팅 예정입니다.

이번 포스팅은 Puppet의 Agent를 그룹화 하여 관리할 수 있는 Environment에 대한 내용입니다.

Environment에 대한 전부를 다루는 것은 아니지만, Environment를 조금이나마 이해하고

사용하는 데 도움이 되셨으면 합니다.

 


 

Puppet  Environments

  Production, QA, Development 같은 다양한 환경에서 Puppet으로 자원을 관리하고자 , Environment Puppet Agent들을 그룹으로 나눠서 관리할 있음.

  Master Server Environment별로 독립적인 Main manifest와 module paths 제공 가능 .

  물론 Puppet Master 분리하여 Agent 독립적으로 관리할 있지만, Environment 통해서 보다 유연하게 관리)

  Agent Node Environment 할당하기 위해서  Agent config 파일을 사용하여 Environment 지정하거나,  혹은 ENC 사용(External node classifier) 있음.

 

 

 

 

< Default Production Environment 적용 >

 

 

 

< Production Development Environment 적용 >

 

 

Puppet  Master에서 Environments 구성

  Environment는 directory로 구분되며, 몇 가지 규약이 있음 .

    - Directory의 이름이 environment의 이름이 됨.

    - puppet master서버의 environmentpath에 존재해야 하며, 일반적으로 $codedir/environment 를 사용.

       * default로 codedir/etc/puppetlabs/code Directory.

    - environment에는 modules directory를 포함할 수 있으며, 이 경우에는 해당 경로는 environment의 default modulepath의 일부가 된다.

   - manifest directory를 포함할 수 있으며,  그 디렉토리가 해당 environment에 default main manifest가 됨.

   - environment에서 environment.conf 파일을 포함할 수 있으며, 이 경우에는 modulepath와 manifest를 포함한 몇 가지 설정이 override될 수 있음. 

       * 특정 environment의 directory에 위치

 

< Environment 내의 설정파일 >

 

 

다음은 environments dev, production, zigimani 디렉토리가 생성된 구성 예제임.

 

 

< environment 구성 예제 : production, dev, zigimani 라는 3개의 environment 각각 존재 >

 

 

 

Agent 설정 파일로 Environment 설정하기

  • Agent node puppet.conf 설정 파일의 agent 혹은 main config section에서 설정 가능.

 

 

 

 

Environment 존재하지 않는 경우

  •Agent node 구성되지 않는 environment 할당될 없음.

  만약 environmentpath 디렉토리에 해당 environment 존재 하지 않는 경우에는 Puppet master 해당 Catalog

     컴파일이 실패함.

  , default environment production 없는 경우에는 agent 카탈로그를 검색. (Fail 아닌 Successfully)

Posted by 네떡지기

티스토리 툴바