String 클래스는 자바 개발자에게 있어서 다른 클래스 객체와는 다르게 다뤄진다.
먼저 다음과 같이 new String을 하여 초기화 할 수 있다.

String string = new String("The Plming Space");    ← 이러한 방법을 추천하지는 않는다.

혹은 다음과 같이 초기화도 가능하다.

String string = "The Plming Space";

문자열을 비교할 때는 equals 메서드와 혹은 == 동등연산자를 이용해서 비교가 가능하고,
때에 따라서 어떤 경우에 true를 리턴하는지를 확인하는 것이 여기서의 목표이다.

다음의 코드를 확인하면,

class Equals {

public static void main(String[] args) {
Double object1 = new Double("7.2");                               // 두 개의 Double 객체 (Rapper Class이용)
Double object2 = new Double("7.2");
System.out.println
("For Double objects both 7.2");
System.out.print("\t object1 == object2 is " );
System.out.println(object1 == object2);
System.out.print("\t object1.equals(object2) is ");
System.out.println(object1.equals(object2));

double prim1 = 7.2;                                                     // 두 개의 primitives double 값
double prim2 = 7.2;
System.out.println
("For double primitives both 7.2");
System.out.print("\t prim1 == prim2 is " );
System.out.println(prim1 == prim2);

String string1 = "7.2";                                              // 두 개의 String 문자열의 값
String string2 = "7.2";
System.out.println("For Strings both 7.2");
System.out.print("\t string1 == string2 is " );
System.out.println(string1 == string2);
System.out.print("\t string1.equals(string2) is ");
System.out.println(string1.equals(string2));
}
}

결과값 (라인값은 편의상 붙인 것임)
1: For Double objects both 7.2
2: object1 == object2 is false 
3: object1.equals(object2) is true
4: For double primitives both 7.2
5: prim1 == prim2 is true
6: For Strings both 7.2
7: string1 == string2 is true
8: string1.equals(string2) is true

object1.equals(object2) 에서는 true이다. 왜냐면 두 개는 동일한 값을 가지고 있기 때문이다.
하지만, 동등연산자로 비교한 2번 라인에서는 false이다. 이는 두 개의 객체가 서로 다른 객체이기 때문이다.
5번 라인의 primitive 타입의 동등연산자 비교는 true이다. 이는 primitive는 단순히 값만을 비교하기 때문이며
두 개의 값은 동일하기 때문에 true를 리턴하게 된다. 또한, primitive는 객체가 아니기 때문에 equals()를 이용해서 비교할 수는 없다.
 문자열 string1과 2의 비교에서는 equals()와 == 동등연산자 모두 true 값을 리턴하게 된다. 이러한 결과는
The Java Language Specification 에 설명되어 있다. "동일 패키지내의 동일한 클래스 안에 있는 리터럴 문자열은 동일한 String 객체를 참조한다."

 The Java Language Specification에서 "문자열 리터럴은 String.intern() 메소드를 사용하여 유일한 인스턴스들을 공유하므로서 'interned'된다. (아래 예제를 참고하면 이해할 수 있다.)

 다시 다음과 같은 예제를 살펴보면,

class NewEquals {

public static void main(String[] args) {
String s1 = new String("Plming");
String s2 = new String("Plming");
String s3 = "Plming";

System.out.println("For new Strings s1 and s2");
System.out.print("\t s1 == s2 is ");
if (s1 == s2)
System.out.println("true");
else
System.out.println("false");
System.out.print("\t " + "s1.equals(s2) is ");
if (s1.equals(s2))
System.out.println("true");
else
System.out.println("false");

System.out.println("For Strings s1 and s3");
System.out.print("\t s1 == s3 is ");
if (s1 == s3)
System.out.println("true");
else
System.out.println("false");
System.out.print("\t " + "s1.equals(s3) is ");
if (s1.equals(s3))
System.out.println("true");
else
System.out.println("false");
}
}

결과값
1: For new Strings s1 and s2
2: s1 == s2 is false
3: s1.equals(s2) is true
4: For Strings s1 and s3
5: s1 == s3 is false
6: s1.equals(s3) is true

3개의 문자열은 모두 같은 값으로 생성되었다. 그래서 equals()를 이용하여 비교하면, 모두 true 값을 얻을 수 있다. 그러나, s1과 s2는 서로 다른 객체이다.(당연히 new를 이용했으므로) 이 둘은 동일한 값으로 생성되었으에도 불구하고 서로 다른 객체이기 때문에 == 동등연산자를 이용하여 문자열을 비교한 2번, 5번 라인의 결과값은 false가 된다.

  The Java Language Specification에서는 new 명령어를 이용해서 새로운 객체를 생성 할 경우에는 String.intern 메소드를 거치지 않지만, 문자열 리터럴의 값은 String.intern을 거쳐서 나온 String이라고 한다.
 동일한 값을 가진 문자열이라도 서로 다른 객체로 생성된 것들은 다른 공간을 사용하게 된다. 이러한 것을 해결하기 위해서  The Java Language Specification에서는 intern() 메소드를 사용하여 문자열들이 공통의 문자열 pool을 사용할 수 있도록 사용자가 만들 수 있다고 한다. 다음의 예제가 그것을 보여준다.


class NewInternString {

public static void main(String[] args) {
String s1 = new String("Plming");
String s2 = new String("Plming");
String s3 = "Plming";

s1 = s1.intern();                                      // intern 메소드 사용

System.out.println("For Strings s1 and s2");
System.out.print("\t s1 == s2 is " );
if (s1 == s2)
System.out.println("true");
else System.out.println("false");
System.out.print("\t " + "s1.equals(s2) is ");
if (s1.equals(s2))
System.out.println("true");
else System.out.println("false");

System.out.println("For Strings s1 and s3");
System.out.print("\t s1 == s3 is " );
if (s1 == s3)
System.out.println("true");
else System.out.println("false");
System.out.print("\t " + "s1.equals(s3) is ");
if (s1.equals(s3))
System.out.println("true");
else System.out.println("false");
}
}

결과 값

1: For new Strings s1 and s2
2: s1 == s2 is false
3: s1.equals(s2) is true
4: For Strings s1 and s3
5: s1 == s3 is true
6: s1.equals(s3) is true

 이번에는 s1을 intern() 메소드를 이용하여 s1의 문자열을 문자열 상수pool에 보내었다. 이는 기존에 문자열 상수 pool에 s1이 가지고 있는 문자열과 동일한 값이 있는지 확인을 하고 동일한 문자열이 있으면 같은 것을 가리키도록 해준다. 즉, 생성되어 있는 공간은 한 개뿐인 것이다. 여기서는 동일한 문자열을 이미 s3에서 문자열 상수pool에 만들어놓았기 때문에 s1은 s3가 만든 문자열 상수pool을 동일하게 가리킨다.

 하지만, s2 문자열의 경우에는 여전히 문자열 상수pool을 가리키지 않고 자신이 생성한 객체로 가리키기 떄문에 2번 라인에서는 false가 된다.
 
 이 내용을 종합해볼 때, 동일한 String 값을 비교하는 데 있어서 제일 확실한 방법은 equals() 메소드를 이용하는 것이라는 것을 알 수 있다. 만약 동일한 문자열 값을 가지고 작업을 할 경우에 문자열을 intern()을 이용하여 문자열 상수pool에 넣어주면, equals() 메소드가 아닌 == 동등연산자만으로도 원하는 결과값을 빠르게 얻어낼 수 있다.

 

class Animal{
 private void show()
 {
  System.out.println("animal");
 }
}

class Human extends Animal{
 public void show()
 {
  System.out.println("Human");  
 }
}

class Test {
 public static void main(String args[])  {  
  Animal a = new Human();
  a.show();
 }
}

compile error : show() has private access in Animal

a 객체는 a의 명세를 가지고 메소드를 호출하는 데, a의 명세에서 보면, show는 private이기 때문에
실행 시에는 실제 객체가 생성된 Human show()에 접근하겠지만, 컴파일 시에는 명세만으로 가지고
검사를 하기 떄문에 컴파일 에러가 발생하게 되는 것이다.

Exception (예외상황)

오류 : 프로그램이 정상적으로 수행이 안되는 상황<실행시에 발생하는 것>
         Throwable 클래스를 상속 받음. (Exception, Error)
  1. Error : 심각한 오류. 처리할 수가 없음.
               하드웨어적인 오류가 많음.
  2. Exception : mild한 오류. 소프트웨어적인 오류.
                      오류 발생시 처리 가능. → Exception Handling
                     


Exception
1. Checked Exception
    반드시 처리해줘야 할 Exception을 처리하지 않았을 때, 컴파일 시에 점검해주는 오류.
    프로그램 자체의 문제가 아니라, 실행 환경상 발생하는 문제.
    프로그램 개발 시 발생 여부 예측 불가능.
    반드시 Exception Handling 이 필요.

2. Unchecked Exception
    프로그램 자체의 문제(잘못 작성)
    실행 시 100% 발생
    Handling보다 프로그램을 수정하는 것이 맞다.



예외 처리 : try, catch , finally, thorws
예외 발생 : throw

Call Stack 메커니즘으로 그 오류를 발생시킨 곳으로 따라감. 최종적으로 JVM이 처리를 하게됨.




try{
      Exception이 발생할 가능성이 있는 code.
      예외 발생 시, 오류객체 생성
}catch(오류객체타입오류객체)
{
      Handling 코드
}



◇ 실행 순서
try{
    1:
    2: 오류발생
    3:
    4:
}catch(   ){
    5:
}
    6:

1→2→5→6  [5번라인에서 오류처리시]
1→2→5→종료 [5번라인에서 오류 미처리시]


◇ 계층적 Exception
    A_Exception/ B_ExceptionextendsA_Exception/C_Exception extendsB_Exception인 경우


     try{
    1: AE 발생                  
    2: BE 발생
    3: CE 발생
    4: DE 발생
}catch(AE a ){
    5:
}catch(BE a ){
    6:
}catch(CE a ){
    7:
}
    8:

   1,2,3의 경우에 어떠한 Exception이 발생할 경우에도 다 5번에서 처리를 하고 끝이남.
   상속의 계층성에 의해서 AE에서 하위객체인 BE와 CE모두 처리가 가능. 따라서 예외가 이처럼
   계층적으로 되어 있을 경우에는,

     try{
    1: AE 발생                  
    2: BE 발생
    3: CE 발생
    4: DE 발생
}catch(CE a ){
    5:
}catch(BE a ){
    6:
}catch(AE a ){
    7:
}
    8:
   
   이렇게 역 계층적으로 예외를 처리해주어야 올바르게 처리를 할 수 있다.
   하지만, 이러한 경우에도 DE을 처리할 수가 없다. 그렇다면 8번은 DE 발생 시 처리가 불가능하다.
   외부의 자원을 사용할 경우에 만약 8번 라인이 그것을 해제하는 부분이라면, 문제가 발생할 수 있다.
   그래서, 무조건적으로 처리를 해야되는 구문이 있다면,(예외의 처리 여부를 떠나서) 다음과 같이
   finally를 써서 작성한다.

     try{
    1: AE 발생                  
    2: BE 발생
    3: CE 발생
    4: DE 발생
}catch(CE a ){
    5:
}catch(BE a ){
    6:
}catch(AE a ){
    7:
}finally{
    8:  // 무조건 처리.
}


◇ API에 있는 메소드 중에 throws 하는 메소드 사용 시에는 반드시 try~catch로 예외처리를 해주어야함.
    해당 throws에 맞는 예외를 처리.

   ex) java.lang.Thread 에 Sleep API
         sleep
              -  public static void sleep(long millis)    throws InterruptedException 

반드시 try~catch를 해주지 않으면 컴파일 에러가 발생한다.



◇ 함수 호출 시 예외처리


void CallMethod()
{
     try{
      TE.testException();   // testException 에서 예외가 발생 가능성이 있다는 것은
                                    // 호출하는 메서드에서도 발생 가능성이 있다는 것을 말함.
                                    // 따라서 호출해서 처리되는 곳에서 예외처리를 안하면
                                    // 호출시킨 곳에서 예외 처리를 해주어야 함.
    } catch(AE e1) {
 
    } catch(BE e2) {

    }
 }
}

void testException() throws AE,BE{
     // 익셉션 발생 가능 코드
     // 이 곳에서 예외 처리를 하는 것이 아니라, call stack 메커니즘에 의해서 이 메소드를 호출한
     // 곳으로 보내서 예외를 처리. 어떠한 예외인지 알려주기 위해서
     // 메소드 선언 시에 throws를 이용해서 발생 가능한 예외를 사전에 미리 알려줘야 함.
     // 만약 이 메소드에서 try{} catch{}를 해서 바로 예외를 처리해주면, throws 안 씀.
}


◇ Exception 클래스 만들기
   public class 만들고자하는Exception명  extends  상속받을상위Exception  {
             Default생성자() {}                                   // 반드시 필요한 것은 아니나
             생성자(String msg) { return super(msg) }  // 일반적으로 필요에 의해서 만드는 최소한의 메소드
   }

  Ex]  public class PlmingException  extends  Exception  {
             PlmingException() {}
             PlmingException(String msg) { return super(msg) }
   }


◇ 사용자 Exception 발생시키기

   public class PlmingException  extends  Exception  {
             PlmingException() {}
             PlmingException(String msg) { return super(msg) }
   }

 public void catchExcetpion()
 {
          try{
             TestException();
          }catch(PlmingException pe){
               Stinrg str = pe.getMessage();
               System.out.prinln(str); //생성자로 넣어준 문자열을 출력
          }
 }

 public void TestException() throwsPlmingException{
    PlmingException PE = new PlmingException("문제점");  // 생성자로 문자열을 넣어준다.
    throw PE;
}



◇ printStackTrace()
  Exception이 발생한 경로를 출력해주는 것.



◇ Exception Overrding
  1. return type, argment list
  2. access modifier
  3. exception → 부모 것이 throws 한 것만 throws 할 수 있다. ( throws 하지 않아도 됨.)
                    → 개수는 상관없다.
                    → 부모가 던진 것을 하위 Exception에서 던질 수 있다.


   AE
  ↑  ↑
BE  CE
 ↑
DE

  ▷ public void go throws AE{ }
     
      public void go throws BE, CE, DE { }    - 가  능 : 부모의 throws를 상속받은 것을 써도 됨. 개수 상관없음.


  ▷ public void go throws AE{ }
     
      public void go{}                                 - 가  능 : 부모의 throws를 안 받아도 상관없음.

      public void go throws BE, CE, DE { }   - 불가능 : 바로 상위 클래스에서는 throws를 안했으므로.
 

CI (Continuous Integration) / CD (Continuous Delivery)

핵심은 SW 제품을 언제든 출시 가능하게 완전무결한 상태 소스코드를 유지하는 것이다.

컨티뉴어스 딜리버리를 효과적으로 수행하는 데 필요한 기술적 토대는 ‘SSO221T(Single Source of Truth)’다. 우리나라 말로 하면 ‘하나의 소스 저장소’ 혹은 ‘단일 소스 저장소’가 된다. SSOT는 세계에 분산된 개발 조직 간 효율적 협업을 위해 데이터센터를 분산 관리하는 것이 아니다. 중앙에 하나의 소스 저장소로 관리해야 한다 .

에자일 개발방법론 TDD(Test Driven Development)

http://www.etnews.com/20160105000244

지속적 통합이란 개발 당시의 코드(baselinecode)와 개발 완료 후의 차이가 극심하여 통합시 다양한 변화와 의존성 문제 해결에 개발 시간보다 더 많은 시간이 소요되는 문제를 해결하기 위해, 통합 작업을 초기부터 계속적으로 자주 수행하여 지속적으로 소프트웨어의 품질 제어를 적용하고자

Today Keys : Unikernel, Container, Docker. specialised, single, address, space, ClickOS , Clive , Drawbridge  ,HalVM , IncludeOS , Ling , MirageOS , OSv , Rumprun ,Runtime.js , UniK

오랜만에 남기는 이번 포스팅은 Unikernel이라는 기술에 대한 첫 번째 포스팅입니다.

Unikernel은 올 초에 Docker에 Join되면서 조금 더 많은 관심을 받고 있는 듯 합니다.

Rethinking Cloud Infrastructure라는 문구가 Unikernel 웹이나, Unikernel System 웹에서 나오고 있지만,

개인적으로는 Cloud보다는 IoT에 조금은 더 가깝지 않을까 생각해봅니다. ^^;

Unikernel에 관련 1차 포스팅이기 때문에 추후에 내용은 수정/보완 될 수 있을 듯 싶습니다.

Unikernel 이란?

•Unikernels are specialised, single-address-space machine images constructed by using library operating systems.

•별도의 OS Kernel을사용하지않고,  Application을서비스하는데필요한 Kernel의특정  라이브러리만을포함하여 Compile하여,

    Hypervisor 혹은 Baremetal 등에서바로서비스가가능하도록지원.

• Haskell이나 Erlang와같은 Type-safe 언어는물론, C/C++/Java/Python과같은일반적인언어를사용하여 Build 가능. 즉, Application에구현하기위한언어에제약이없이 Unikernel을사용가능.

  ※ Unikernel을컴파일하기위해서사용되는 Library OS에따라서지원되는개발언어는다름)

• 2016년 1월 21일에 Unikernel System은  Docker 에합류

Unikernel  특징

•Application 구동에필요한라이브러리만포함되기때문에매우가벼움.

•불필요한서비스가사용되지않기때문에매우빠르게구동(< 1ms)

•Application에필요하지않는불필요한 Kernel은배포되지않기때문에, 공격노출을줄여보안이강화

•General한목적 / Multi-user 컴퓨팅에는적합하지는않음.

Unikernel 주요프로젝트

• Unikernel   웹사이트(http://unikernel.org/) 에서는 Unikernel와관련된 Open Source 프로젝트로아래의 11개프로젝트가소개.

     - ClickOS / Clive / Drawbridge  /HalVM / IncludeOS / Ling / MirageOS / OSv / Rumprun /Runtime.js / UniK

• Unikernel과관련된주요프로젝트의내용은아래와같음.

Container과의비교

•Unikernel은 Container와동일하게 Immutable Infrastructure를제공

•Unikernel은 Container와유사하게 Resource 사용에대한 Overhead가적음.

•Container가 Host OS의기본 Kernel을공유하는반면에 Unikernel은개별 App을구동하기위한일부라이브러리에대해서 

   Applicaion과 함께 컴파일하여 해당 Application에서 독립적으로사용

•Container에서도하나의 Kernel을공유했을경우에발생하는이슈와보다 Container에최적화하기위해,

   CoreOS, Atomic(Redhat 지원프로젝트), Photon OS(VMware), Snappy(Ubuntu)와같은 Container를 전용의 OS를사용하여

   Container별로개별 Kernel을사용하면서크기를감소시키기도하지만, Unikernel의경우에는 Application 구동에필요한최적의

   Library만을포함하기때문에보다최적화시킬수있음. 
 

Library OS  특징

• single address space를사용하기때문에 User space와 Kernel space 간의전환이필요없기때문에, 따라서, Context switching 없이하드웨어로직접적인접근이가능하게하여성능을향상

• Library OS가구동되기위한특정하드웨어의 device driver가필요로하는데, 하드웨어의변화속도가빨라짐에따라서이러한 driver를정기적으로다시만들어야하는부분이부담으로작용하지만, OS 가상화로인해서이러한부담은해소될수있음.
•Hpyervisor에는 stable한가상하드웨어를제공하기때문에 library OS가이러한환경에서동작할경우에 Hardware device driver에대한이슈를해결할수있음.

,  

Today Key : Unikerenl, 유니커널, rump, Unik, provider, OSv, 관리도구, Open, Source

오늘은 지난 포스팅에 이어서 Unikernel의 2번째 포스팅입니다.

이번 포스팅에서는 Unikernel 응용 프로그램을 손쉽게 컴파일하고 관리할 수 있는 도구인 UniK에 대한 첫 번째 내용입니다.

다양한 Unikernel 환경을 통합 관리를 해줄 수 있는 오픈소스 프로젝트로, Unikernel 홈페이지에서 살펴볼 수 있는

공식 오픈소스 프로젝트이기도 합니다.

UniK란?

•Unikernel 응용프로그램을컴파일하고배포할수있게도와주는오픈소스도구. (오픈소스프로젝트로진행)

•UniK는 Local 및다양한가상화, 클라우드환경에서컴파일된이미지로부터생성된 Instances들을실행하고관리.
    즉, 작성된코드를배포하고자하는환경에따라서컴파일하고이렇게컴파일된이미지를다양한환경에서
    서비스가가능한 Instance 형태로배포하고, 관리를할수있다.

•기존에 Unikernel을구현하는다양한 Library OS 형태의프로젝트를하나의관리도구로서손쉽게사용할수있다.

UniK에서지원되는 Unikernel Type.

•rump: Python3 , Node.js , Go , C/C++

•OSv:  Java

  ※향후에 Unikernel 및 Language는추가될예정. 현재로드맵상으로는 MirageOs가다음에추가될예정.

UniK에서지원되는실행가능한환경(Provider)

•Virtualbox

•AWS

•vSphere

•QEMU

※ OpenStack은향후지원  예정(Roadmap)

UniK를사용한구현예제

•Unik를 사용하여 간단한 Web서버 코드(Python)를 Unikernel 형태로 Build하고,

   배포하는 예제를 통해서 UniK가 어떻게 동작하는지 보겠습니다.

•이번 예제에서는 Provider로는 Local에서 VirtualBox를 사용하였고, Web 서버 코드는 Python, Unikerenl Type은 rump를 사용합니다.

•Unik 설치 후에, Unik를 사용하기 위한 Daemon을 띄우면 아래와 같이 데몬이 뜨게 됩니다.
   실제로는 각 Provider에 따라서, 별도의 데몬이 생성됨. (관련 내용은 다음 포스팅에서 다룰 예정입니다.)

   우선 여기서는 Unik를 사용하기 위해서 Daemon을 먼저 띄운다고 생각하시면 됩니다.

•Unik Daemon은 아래와 같이 하나의 VM 형태로 구동되게 됩니다. 

   즉, Daemon을 실행하면, Provider에(여기서는 virtual box) 하나의 VM이 생성되게 됩니다. 

   그리고 이 VM을 통해서 Unik의 Instance를 생성 및 관리를 하게 됩니다 . 

•이제, Web서버를 Unikernel 형태로 만들겠습니다.

   현재 디렉토리를 보면, svr.py라는 파이썬 코드가 있으며, manifest.yaml이라는 설정 파일이 있습니다.

   manifest.yaml은 UniK를 통해서 Unikernel 이미지를 만들 때, 어떤 것을 참조해서 만들 것인지에 대한 설정을 넣는다고

   생각하면 되는데, 여기에서는 svr.py를 가지고 만들겠다는 설정이 간단히 들어있습니다.

•Unik로 이미지를 만들기 전에, 먼저 파이썬 코드가 정상적을 동작하는지 봅니다.

•코드를 실행하고 웹에서 확인을 해보면, 다음과 같이 Local Host에서 간단한 웹화면이 표기 됩니다.

•이제 본격적으로 UniK를 통해서 Unikerel 이미지를 생성합니다.

    이미지가 작아서 안보일 수 있지만, 내용을 보면,

    unik build --name zigiWebImg --path ./ --compiler rump-python-virtualbox --provider virtualbox

•unik build라는 명령으로 어떤 이미지를 만들고, 어떤 Unikernel Type 및 언어, Provider를 할 것인지 등을 지정해서 이미지를 만듭니다.
   생성된 이미지는 약 127MB입니다.

•만들어진 이미지를 통해서 Instance르 생성합니다.
   unik run --instanceName zigiWebInstance --imageName zigiWebIm

•이미지를 통해서 발 인스턴스를 생성하게 되는 데, 이미지 이미지 생성 시에 필요한 사항을 넣었기 때문에

   Instance 생성 시에는 바로 이름만 가지고 생성할 수 있습니다.

•Instances는 아래와 같이, Hyperevisor 위의 하나의 VM으로 생성이 되게 됩니다.

•그리고 해당 VM이 받은 IP를 통해서 접속을 해보면, 아래와 같이 정상적으로 하나의 Web서버가 만들어져서 정상적으로

   구동이 된 것을 볼 수 있습니다.

결과적으로, 하나의 웹서버 코드를 가지고 바로 이미지를 컴파일 하게 되면 해당 웹서버가 동작하기 위한 커널의 라이브러리와 Application의 라이브러리를 가지고 작은 디스크 이미지를 만들게 되고, 이를 통해서 Instance를 생성하여 서비스를 할 수 있게 됩니다.

가상화환경에서서로다른네트워크를사용하는 VM간의라우팅이필요로한경우가있는데,

별도의 Router용 VM이아닌일반 Linux를사용하여아주간단한 Router 역할을할수있음.

Ip_forward 를활성화하면, 해당시스템안에서커널이처리하는패킷에대해서외부로 forwarding 가능.

※만약, ip_forward가활성화되지않은경우에는수신된패킷이자신의것이아니면 Drop 됨.

※ CentOS 6.7 기준

== 활성화방법 ==

# cat /proc/sys/net/ipv4/ip_forward

1

※ Enable : 1  /   Disable : 0

◎ 해당 설정을 지속시키기 위해서 sysctl.conf 을 수정.

# cat /etc/sysctl.conf

# Kernel sysctl configuration file for Red Hat Linux

#

# For binary values, 0 is disabled, 1 is enabled.  See sysctl(8) and

# sysctl.conf(5) for more details.

# Controls IP packet forwarding

net.ipv4.ip_forward = 1

※인터페이스별로활성화상태확인

# cat /proc/sys/net/ipv4/conf/eth1/forwarding

1

==  NAT처리 ==

Internal Interface : eth1

External Interface : eth0

# /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# /sbin/iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT

# /sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

Today key : Puppet, 퍼펫, manifest, autumation, 자동화, 설치, install, master, agent 

이번 포스팅은 Puppet에 대한 포스팅입니다.

약 2년여전에 관련 Automation for Networker라는 주제로 포스팅을 할 때 ansible과 함께 잠깐 정리했던 내용을

다시 정리해보려고 합니다.  아무래도 제 포스팅이 대체로 제가 다시 보기 위해서 정리하면서 공유하는 게 목적이오니~

보시는 분들은 참고하시면 되겠습니다 ^^

그리고 혹시 잘못되거나 수정해야 할 부분이 있으면 덧글 부탁드립니다! ^^

Puppet를 사용하기 위한 요구사항

◇ 하드웨어

    · 최소 Puppet master server : 2CPU Core, 1GB RAM
    · 약 1,000 node 관리를 위해서 2-4 CPU Core, 최소 4 GB RAM.

◇ 지원 OS

    · Redhat Enterprise Linux 7,6,5

    · Debian 8 “Jessie”, Debian 7 “Wheezy”

    · Ubuntu 16.04 LTS “Xenial Xerus”, 15.10 “Wily Werewolf”, 14.04 LTS “Trusty Tahr” , 12.04 LTS “Precise Pangolin”

    · Fedora 23, 22

    · Windows Server 2012 R2, 2015, 2008 R2, 2012, 2008

    · Windows Vista, 7, 8, 8.1, 10

    · OS X 10.11 El Capitan, 10.10 Yosemite, 10.9 Mavericks

    · *SUSE Linux Enterprise Server, version 11 and higher

    · *Gentoo Linux

    · *Mandriva Corporate Server 4

    · *Arch Linux

    · *Oracle Solaris, version 10 and higher (Puppet performs limited automated testing on Solaris 11)

    · *AIX, version 5.3 and higher

    · *FreeBSD 4.7 and later

    · *OpenBSD 4.1 and later

    · *HP-UX

※ *표기는 Puppet Open-source 버전에서는 미지원하고, Puppet-Enterprise에서 지원.

◇ Master와 Agent에 따른 지원 플랫폼 (PE 기준)

◇ 네트워크 요구사항

    · Firewall

       - Master Server는 8140 Service Port가 오픈되어야 함. (in-bound)

    · Name resolution

       - 모든 노드는 유일한 Hostname을 가지고 있어야 함.

       - 정방향, 역방향에 대한 DNS 모두 설정 필요.

           * DNS 미 사용시에는 Node의 Hosts 파일에 해당 내용이 포함되어 있어야 함.

◇ 기타 필요 패키지

    · Ruby 2.1.x, 2.0.x, 1.9.3

    · Facter 2.4.3 이상, Hiera 2.0.0 이상, json gem, rgen gem 0.6.6 이상

    · msgpack gem (Optional)

Puppet 설치

◇ 설치환경 및 패키지 (TEST 환경)

    · CentOS 7.2 (Master / Agent)

    · Puppet 4.5   

    · Hosts에 Node 정보 등록 (DNS 미사용)

 ◇ Package 레포지토리 설치 

    · rpm -Uvh https://yum.puppetlabs.com/puppetlabs-release-pc1-el-7.noarch.rpm

       - 각 Linux ~~ 및 버전별로 다름.

       - https://docs.puppet.com/puppet/latest/reference/puppet_collections.html

◇ Puppet package 설치 

    · yum install puppetserver

        - puppetserver 설치 시, dependency 때문에 puppet-agent도 함께 설치

        - 본 테스트 시에는 Master Node와 Agent Node의 설치는 동일하게 진행하였음. (여기까지 진행 후, VM 복제)

◇ Master와 Agent Config 설정

    · Hostname / Domain

        - Master : puppet

        - Agent : agent01

        - Domain : puppet.local

    · puppet.conf 설정

        - Master : [master] 섹션에 certname 추가

           [master]

           certname = puppet.puppet.local

        - Agent : [agent] 섹션에 certname 추가

           [agent]

           certname = agent01.puppet.local

    · DNS 혹은 hosts 파일에 master와 agent01 정보 추가 

    ·

 ◇  Puppet Master 노드 구동 

    ·  #puppet master --no-daemonzide -d -v

 ◇ Puppet Agent 노드 구동 

    ·  #Puppet agent --server master-fqdn --no-daemonize --verbose

 ◇ Puppet  인증 확인 

    · Master와 Agent 간의 통신을 위해서 인증 작업을 거쳐야 함.

    · Agent 등록 후(Agent가 Master에 접속 후), 현재 인증된 전체 리스트를 확인하기 위해서

      # puppet cert --all and --list 

      명령으로 확인을 하면, 아래와 같이 표기

      puppet.puppet.local (Master)에 대한 정보와 agent1.puppet.local(agent) 정보가 확인되는 데,

      아직 agent가 등록만 되고, 인증이 되지 않았기 때문에 Node 제일 앞에 '+' 표기가 agent1에는 되어 있지 않음 

 ◇ Puppet 인증 및 확인 

    · Master에서 agent1 Node 인증

      # puppet cert --sign agent1.puppet.local

    · 인증 후, 다시 인증된 리스트를 확인하면, agent1 node가 인증된 것을 확인 할 수 있음. (앞에 '+' 표기)

 ◇ Puppet Agent 노드 구동 

    · Agent 노드를 다시 실행해보면, 인증받은 인증서로 master와 통신을 성공하고, client가 동작하면서 catalog를 적용

Puppet Manifest 확인

◇ 기본 Manifest 테스트

    · /etc/puppetlabs/code/environments/production/manifest 디렉토리에 아래와 같은 manifests를 작성하고,

       agent를 재기동해보면, manifests가 agent1에 적용된 것을 확인할 수 있음.

    ·  기타 manifest 적용하는 부분에 대한 내용은 이후 포스팅에서 다룰 예정이며,

        아래의 기존 포스팅에서도 일부 확인 가능합니다.

※ 기존 포스팅 확인 : http://zigispace.net/791

                            http://zigispace.net/789

Puppet Part 2 .

Manifest

    - Puppet languatge 파일로, '.pp' 확장자를 가진다.

    - Target 시스템에적용되어야하는 Resource와 Value를지정하는일종의명세서같은역할.

    - UTF8 인코딩사용

Manifest 기본구성형식

○ Node

   - 다수의 Puppet Agent 적용 시에, 각 Node를 구분하기 위한 Keyword이며 이는 Device의 Hostname을 Node 뒤에 써주면 해당

   - Hostname에을 가진 Device에 대해서만 해당 Attribute가 적용

○ Resource

   - Puppet이 관리하는 Configuration의 구성요소, File, Service, Package, User등의 Type과 Attribute를 갖는다.

   - Defined Type과 Custom resource type이있음.

○ TITLE

  - 하나의 Resource Type에서 유일한이름으로사용되어야함.

  - 중복된 TITLE 사용시에는 Manifest 컴파일시의에러발생

  - 서로다른 Resource 간의 TITLE 중복은가능.  (Ex. package 'ntp', service 'ntp'

  - Resource Type에따라서 Target System의특정 Resouce를뜻하기도하며(이러한경우의 'namevar' 속성이라고함),

    단순히, '이름'을뜻하기도함.

  - namevar의경우에는하나의 resource type에하나의값을뜻하는경우도있지만, 어떤경우의 namevar는해당이름만으로는

    명확하게알수없는경우가있다. 예를들어서, service의 mysql은 Target System 내에설치된 mysql 서비스로명확하지만,

    package의 mysql은 mysql을받아오는방법에따라서다를수있다. (ex. Yum, gem .. )

  Ex) File  : File의 절대 경로/파일명

        Package / Service : 실제패키지나서비스

○ Attribute

    - 해당 Resource의 설정되어야 하는 속성

    - manifest에서 target system에적용하고자하는속성값을선언
    - 소문자로쓰여지고, ""를사용하지않음.

○ VALUE

    - 특정 Resource의 Attribute에 적용되는 내용, 상태 등을  나타내는 값.

지정가능한 Resource Types

Resource  예

File Resource

 ▪ path : 파일에대한경로지정. 만약이속성을선언하지않으면 default로 Title을 path 값으로갖게됨.

 ▪ ensure : 지정된파일의생성여, 어떤종류인지지정. (present, absent, file, directory, link)

 ▪ contents : 실제파일의내용. 이속성은 source  / target 속성과함께사용할수없음.

 ▪ source : 복사할파일의 Source 지정. 이속성은 contents / target 속성과함께할수없음.

                   puppet, file, http 지정가능.  Ex) 'puppet:///modules/nfs/conf'

 ▪ target : link를생성시, 사용. Symlinks type만지원. (link 생성시의원본경로)

                 contents, source 속성과함께사용할수없음.

package Resource

 ▪ provider: 동일한패키지가다양한 Source에서관리되는경우에받아올곳을지정.

                     apt, dpkg, gem, rpm, pip, yum windows, zypper 등

 ▪name : 패키지명. 만약이속성을선언하지않으면 default로 Title이패키지명이됨.

 ▪  ensure : 패키지의상태. (Default : installed) . 특정버전지정가능

                   present(installed), absent, purged, held, latest

 ▪ install_options  : 설치시의추가적인옵션지정. 이옵션은 package-specific 함.

 ▪ source : 패키지를가져오게될위치. Provider에서자동으로패키지를다운받을수없는경우에사용.

                  예를들어서, yum이나 apt로 provider를지정할경우에는이속성은무시.

service Resource

 ▪ name : service 명. 만약이속성을선언하지않으면 default로 Title이 service명이됨.

 ▪ ensure :  servicer가 running 상태인지아닌지지정.

                    running(true), stopped(false)

 ▪ enable : 시스템이 boot 시에 service가활성화될것인지지정.

                   true, false, manual, mask

 ▪ path :  init scripts에대한경로

Today key : Puppet, 퍼펫, manifest, autumation, 자동화, Architecture, 아키텍처, Catalog, 카탈로그, facts 

지난 번에 이은, Puppet의 3번째 포스팅입니다.

이번 포스팅은 Puppet을 조금 더 이해하기 위한 간단한 아키텍처와 동작 방식에 대한 내용입니다.

우선 짧지만, 정리하는 데로 추가로 올리거나 업데이트 할 예정입니다.

혹시 잘못되거나 수정해야 할 부분이 있으면 덧글 부탁드립니다! ^^

Puppet Part 3

Puppet Architecture 일반

   • Puppet은일반적은 master/agent(혹은 Server/Client) 구조의 Puppet Master와 Puppet Agent로사용.

   • Puppet Apply Application을통한 self-contained(Standalone) 구조로도실행가능.

Puppet를통한 Node 관리를위한 2개의 Main Stage

   • Catalog 컴파일

   • Catalog 적용

Master/Agent 구조에서의기본동작

   • Agent에서는 Puppet Agent App가 Background 서비스처럼동작하고, 하나이상의 Puppet master App가

       동작하는 Puppet Server가동작.

   •Agent는주기적으로(Default 30분) Master에게자신의 facts를전송하고, Catalog를요청

   •Master는 Catalog 생성을위해서컴파일후에 Node에게 Catalog를전송

   •Agent는 Catalog를수신받아서, catalog에정의된내용과현재의 Resource와비교하여 Catalog의내용을적용.

   • Catalog 적용후, Agent는 Report를 Master로전송

Standalone 구조에서의기본동작

   •Puppet Apply를통해서노드를관리

   •일반적으로예약된작업(Scheduled task)혹은 Cron Job으로수행.

   •Master/Agent 구조와마찬가지로 Puppet은노드관리를수행하기위해서컴파일과정을거치게됨.

   •컴파일된 Catalog를통해서 Resouce들을 Catalog에내용대로적용.

   •Catalog 적용후, Report를 Disk에저장

Catalog

• 관리하는자원에대해서각자원에대해원하는상태(Desired state)를기술

• 특정순서로관리를해야하는경우에, 각리소스에설정에대한종속성정보를제공가능.

 • 노드를설정할때(configuring), Puppet agent는 catalog라고부르는 Master 서버로부터전송받은 document를사용.

Catalog Compile

• Puppet은 3가지의설정정보의 main-sources를사용하여 catalog를컴파일함.

    ▫ Agent-provided data

        - agent는 catalog를받기위해서 master에게자신의정보를전송할때아래의 4가지정보를전송.

           1. name.  (일반적으로 certname과같다.)                     2. certficate

           3. facts                                                                                      4. environment

   ▫ External data

   ▫ Puppet manifests

        - main manifests와 Modules ( Puppet Forge로부터다운, 각사이트에서직접작성)

FACTS

•catalog 요청전에 Facter를사용하여시스템의정보를수집.

•puppet은이렇게수집된정보를 facts 정보라하고, 이것은 manifest에서사용될 pre-set variables로사용.

 .

Today key : Puppet, 퍼펫, manifest, autumation, 자동화, class, 클래스, 상속, inherits, 매개변수

개인적으로 정리하는 Puppet의 4번째 포스팅입니다.

이번 포스팅은 Puppet의 Manifest를 모듈화 하여 작성하기 위한 방법인 class 작성 방법과 예제입니다.

기존의 OOP에서처럼, 모듈화하고, 코드의 재사용 등 기존의 OOP의 class와 동일한 쓰임새로 사용된다고 보면 될 것 같습니다.

혹시 잘못되거나 수정해야 할 부분이 있으면 덧글 부탁드립니다! ^^

Puppet Part 4

Puppet  Class

   •manifest에자주사용되는내용들은별도의 Class로구성하여사용가능.

   •별도의 Class로구성하여서로다른 Environment에서동일한 manifest를작성하지않아도됨.

Puppet Class 정의

   •class 키워드사용

   •class명지정

   •class의매개변수지정가능.

         - 매개변수지정방법 : ( Data_Type $변수 = Default_Value)

             * Datatype 선언은필수는아니면, Default로는 any

   •다른 class를상속하는경우에 Inherits 와함께상속받을클래스명입력

   •하나이상의 Resource에대한 Puppet Code 작성

Class 사용법

   •동일한 Manifest에작성하거나, 혹은별개의 Manifest에작성

   •사용하고자하는 manifest에서 include class명으로사용가능

Class 작성예제

※ Class를상속받는경우에는상속하는 Class의동일한 Resource의 Title이중복이되는경우에는

   해당값을 Override 할수있음.

※단,상속시의 Overrding하는 Title을기존선언하는방식과동일하게선언하게되면, 중복선언으로에러가발생하게됨. 

※관련 Manifest 작성은추후포스팅에서또다뤄질예정입니다.

※ Class를상속받는경우에는상속하는 Class의동일한 Resource의 Title의특정속성값을

   추가하고자할때에는Attribute => value대신에 Attribute +> value로표기하면된다. (=> → +>)

Today key : Puppet, 퍼펫, manifest, autumation, 자동화, class, 클래스, module, 모듈

개인적으로 정리하는 Puppet의 5번째 포스팅입니다.

이번 포스팅은 지난 포스팅과 연장선상에 있는 manifest 모듈 작성과 관련한 내용입니다. 

지난 포스팅이 하나의 Environment에 대한 내용이었다면,

이번 포스팅은 다양한 Environment에서 사용 가능한 모듈을 작성하는 내용입니다.

아마도 모듈에 대한 내용은 추가적인 포스팅이 있을 것 같습니다.   

혹시 잘못되거나 수정해야 할 부분이 있으면 덧글 부탁드립니다! ^^

Puppet Part 5

Puppet  Module 1

   •manifest에서 Class를사용하기위해서 Class를정의하기위해서는사용하고자하는 Manifest에서사용할수도있지만,

      Class들을별도의 Manifest 파일로작성할수있음.

   •Class를별도의 Manifest로분리하여 Module로써사용하게되면작성된코드를재사용하거나, 이력관리,

       코드의유지보수에유용함.

   •Puppet을이용하여관리되는 Node를정의하는 Manifest와실제관리되는 Resource에대한 Attribute을선언하는

       Manifest로분리하여작성하는편이유용.

Class 모듈화예제

   •zigispace라는 file 내용을갖는 blog라는파일을생성하는 blog.pp

   •Node의 OS 종류를 file 내용으로갖는 osver라는파일을생성하는 osver.pp

   •blog.pp와 osver.pp의 class를가져다가 node에적용하는 maindev.pp

   •blog.pp와 osver.pp는다른 manifest의다른 node에서도동일하게적용가능.

Puppet  Module 2

   •하나의 environments에서 class를별도의 manifest 모듈로분리하여선언할수도있지만, 다수의 environment에서

     공용으로사용할수있도록구성할수있음.

   •모듈로사용하고자하는 Manifest를 modules 디렉토리의하위에위치

   •특정기능을하는모듈별로, modules 디렉토리하위에서브디렉토리를생성하고, 서브디렉토리하위에 manifests라는

      해당모듈에들어가는 manifest를위치할디렉토리를만들어서 manifest 파일을관리함.

   •modules 디렉토리에서 manifest 모듈을관리할때에는다음과같은규칙으로관리를해야함.

         - modules 하위에 module 이름으로모듈디렉토리를생성

          - 모듈디렉토리하위에는 manifests라는하위디렉토리를생성하고, 이하위디렉토리에서 manifest 파일을생성

          - modules 내의 manifest 파일의 class명은위에서선언한모듈디렉토리를기준으로지정. 

          - 이때, module 이름과동일한이름의 class의경우에는파일명을 init.pp 이라고명명해야함.

          - init.pp 이외의다른 manifest 파일의클래스는클래스선언시, module 이름을포함하여클래스를선언

              * module명::클래스명

              * 기존의프로그래밍에서 namespace를지정하는것과유사함.

           - manifest 파일명은클래스명과동일하게지정. 

Puppet  Module 구성에제

   •zigimod라는 module에 2개의 manifest 파일을구성하고, 사용하는예제

   •modules 하위디렉토리의구성과각 manifest 파일의예제코드

Puppet  Module 3

 •기본 Puppet 속성의 ModulePath 속성이외에 Module 디렉토리를사용하고자 할경우에는 ModulePath에추가해야함.

 •modules 디렉토리에는모듈형태로사용하고자하는 manifest 뿐만아니라 file, plug-in, template 등도추가하여사용.

 •module에서사용하는자원들의종류에따라서개별디렉토리사용.

           ex> manifest는 manifests 디렉토리, file은 files 디렉토리등..

 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/codeDirectory임.

    - 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)

안녕하세요.

네떡지기입니다.

본 블로그에서 나름 오랜(?)기간 포스팅 했었던.. 시리즈인..

Nexus 기초 따라잡기에 대한 PDF판을 공개합니다.

아무래도 시간이 좀 지난거라서 달라진 부분들도  있을꺼고,

미처 잘못 작성된 것을 수정하지 못한 부분들도 있을 수 있습니다.

하지만, 커다란 맥락에서는 큰 부분이 달라지지는 않았으리라.. 생각하고..

달라지는 부분들도 기존의 것들을 알고 있어야 할 것이라고 생각하기 때문에...

2016년 크리스마스를 앞두고... PDF판으로 공개를 합니다.

표지,간지를 포함하여.. 무려. 192페이지에 달하는...

누군가에게는... 도움이 되기를 바라며... ^^

p.s. 2016년에는.. 기존의 포스팅과 더불어... 또 다른.. 장기 시리즈가 시작되지 않을까? 싶습니다..

Nexus_기초따라잡기(공개).z01

Nexus_기초따라잡기(공개).z02

Nexus_기초따라잡기(공개).zip

오랜만에 하는 포스팅은 Cisco ACI에 대한 관련 이슈 공유 내용입니다.

Bridge Domain에서의 기본 설정인 Hardware Proxy와 관련한 이슈 사항입니다.

앞으로 아마도 ACI에 대한 포스팅을 시작하게 될 듯 싶은 데... 우선 정리 포스팅 전에..

어쩌다보니.. 간단한 이슈 포스팅을 먼저하게 되었습니다 ^^;

물론 ACI 이외에도 기존처럼 다양한 포스팅 들도 함께 할 수 있도록 노력하겠습니다. ^^

즐거운 연말되세요!

Cisco ACI Bridge Domain 관련

○ 현상 

  ㆍ MySQL DB Clustering을 위한 MMM(Multi Master Replication Manager) 을 서버에서 사용 중.(Active-Standby)

  ㆍVIP가 Active 서버에서 Standby 서버로 전환될 경우에 정상적으로 통신이 되지 않음.

○ 확인 및 원인 분석

  ㆍACI 내에서 VIP에 대한 정보(IP/Mac Address)가 갱신되지 않음.

  ㆍMMM에서 VIP가 Active-Standby로 전환되면서, IP에 대한 MAC이 변경되었기 때문에 GARP를 보내서,

     Table이 갱신되어야 하나, 정상적으로 이뤄지지 않은 것으로 추정

○ 조치 및 결과

  ㆍBridge Domain의 ARP Flooding 설정을 활성화 상태로 변경 후, DB VIP가 Standby로 넘어감에 따라
     Table이 정상적으로 갱신되는 것을 확인

○ Bridge Domain 관련 내용 

  ㆍBridge Domain은 기존의 전통적인 네트워크의 VLAN 컨셉과 유사. Brocast와 Flooding Domain으로 동작 가능
       - 물론 관련 설정이 활성화 되어 있어야 하며, 완전하게 동일하지는 않음.

  ㆍBridge Domain의 Unknwon Unicast 프레임에 대해서, 아래의 2가지 모드로 동작 가능.

       - Optimized mode : Hardware Proxy

           Mapping Database 사용하여 처리

       - Flood mode : Flood

           Bridge Domain의 Multicast Tree를 이용해서 L2 Unknown unicast가 Flood됨.

  ㆍBridge Domain의 기본 L2 Unknown Unicast의 동작 방식은 Hardware Proxy임.

  ㆍBridge Domain의 ARP Flooding은 Default Disable 상태.  

  ㆍHardware Proxy의 기본동작은 L2 Unknown Unicast에 대해서 Spine으로 보내게 되고, Spine의 Mapping Database에

      해당 정보가 없을 경우, 패킷이 Drop 됨.

○ 정리하면..

ㆍDB서버에서 Active가 Standby로 Failover되면서, VIP가 DB2번기에서 올라오면서 GARP를 발생 시키는 데 기존 Hardware proxy/ARP Flooding Disable에서는 해당 패킷을 Drop시켜서 정상적으로 Table이 갱신되지 않았고, Hardware Proxy  설정을 Flood로 전환하게 되면, ARP Flooding이 같이 Enable되지만, 이 경우에는 해당 BD에 연결이 일시적으로 끊기기 때문에 (Test 시에 Ping 3개정도 빠짐), Hardware Proxy 설정은 유지한 채, ARP Flooding만 Enable로 변경 후, 정상 동작 확인

※ 참조 : Cisco Application Centric Infrastructure Release 2.0 Design Guide

.  

Bridge Domain 관련 설정

* Bridge Domain 설정에서 ARP Flooding 설정을 활성화하게 되면, L3 설정에 아래와 같은 설정이 가능.  

  우선 해당 설정까지는 하지 않은 상태였으나, MMM VIP가 전환되는 데에는 문제가 없었음.

  아래 설정은 어느 경우에 사용되는지는 추가로 확인 필요.

GARP

   - Source / Destination IP는 모두 패킷을 보내는 시스템 IP로 설정

   - Destination MAC은 Broadcast MAC 으로 설정 (ff:ff:ff:ff:ff:ff)

   - 일반적으로 GARP는 Request만 발생하고, Response는 발생하지 않음.

   - IP 충돌을 감지하거나, 다른 시스템의 ARP 테이블을 갱신하기 위해서 사용(특히나, Clustering Solution에서 Active가 전환되는 경우에 동일한 IP에 대한 Mac 주소가 변경되기  때문에 필요)

※ 참조 : https://wiki.wireshark.org/Gratuitous_ARP

안녕하세요.

오랜만에 또 포스팅을 해봅니다.

이번 포스팅은 서버 기초에 대해서 예전에 내부 발표를 했던 내용입니다.

아주 기초를 위해서 작성했던 내용이라서, 서버를 하시는 분들에게는 이미 너무 쉬운 내용일 수 있겠네요. ^^;

혹시라도 도움이 되시는 분들이 계실까해서.. 공유합니다.

- 티스토리에서 한 번에 올릴 수 있는 사진이 정해져 있어서 2번으로 나눠서 올립니다.

요

사진 업로그 갯수로 나눠서 올리는 서버 기초 발표자료 2번쨰 입니다.

안녕하세요.

이번 포스팅은 작년에 포럼에서 발표했던 IAC 관련 발표 내용입니다.

인프라 환경에 대한 변화에 따라서, 필요한 이유..  현재 나와있는 다양한 오픈소스에 대한 내용..

그리고 몇 가지 관련 오픈소스 프로젝트를 소개했던 내용입니다.

이번 포스팅은 얼마 전에 진행한 네트워크 전문가 따라잡기 커뮤니티에서 진행한 멘토링 행사에서 했던,

무엇이든 물어보세요! 라는 세션에 대한 정리 자료입니다.

사전에 커뮤니티 회원 분들에게 다양한 질문을 받아서 정리하고, 당일 멘토들의 다양한 답변을 정리해 보았습니다.

비슷한 궁금증이 있는 분들에게 조금이나마 도움이 될 수 있었으면 합니다.

이번 포스팅은 예전에 정리했던 Ansible 관련한 내용 중에 Install이 빠져 있어서 현재 기준으로 간단하게 포스팅을 합니다.

아마 Ansible을 이용한 다른 포스팅을 시작하게 될 듯 싶어서, 다시 설치를 하는 김에  기존에 설치 내용이 포스팅에 없어서, 

정리를 해봅니다.

  - 기존 포스팅은 ZIGISPACE.NET에서 ansible로 검색하시면 됩니다! ^^

* 설치환경 : CentOS 7

1. Extra Packages for Enterprise Linux 

 Fedora를 쓰는 경우에는 직접 Ansible이 설치가 가능하지만, Fedora 계열의 Redhat이나 CentOS 등을 사용하는 경우에는

먼저 epel-release RPM을 설치.

   * epel = Extra Packages for Enterprise Linux

2. Yum을 이용해서 Ansible을 설치.

3. Ansible 설치 확인

○ 각 Distro에 따른 Ansible 설치는 아래의 홈페이지를 확인하시면 됩니다.

  - Ansible 설치 : http://docs.ansible.com/ansible/intro_installation.html#id13