'이중화'에 해당되는 글 3건

  1. 2011.07.24 데이터베이스 보안 솔루션 도입 및 운영의 허와 실
  2. 2009.01.14 Linux 이중화 (High-Availability) 구성 방법 (1)
  3. 2009.01.14 게이트웨이(Gateway)의 이중화 VRRP/HSRP (3)
2011. 7. 24. 14:28

데이터베이스 보안 솔루션 도입 및 운영의 허와 실

728x90

개인정보보호의 필요성에 따라 데이터베이스 보안 구축이 중요한 과제로 인식되면서 관련 제품 도입이 활발히 이루어지고 있다. 하지만, 현재까지 많은 도입 사례에도 불구하고 실제 안정적으로 적용되어 운영되는 사례는 놀랍게도 드물다. 여기에는 어떠한 문제점이 있는지 살펴보고, 오라클 데이터베이스 보안 솔루션은 이를 어떻게 극복할 수 있는지에 대해 설명하고자 한다.

 

개인정보보호와 관련된 흐름

2008년부터 2010년 최근까지 국내에서 발생한 주요 개인정보 유출 사고의 내용을 <표 1>을 통해 확인할 수 있다. 해외의 경우와 마찬가지로 국내에서도 대규모개인정보 유출 사고를 겪으면서 기업들에게 보안 강화 조치를 의무화할 수 있는규제준수 법안(Compliance)의 필요성이 대두하였다.

그 결과로 2009년 1월 28일[정보통신망 이용 촉진 및 정보보호 등에 관한 법률(정보통신망법)]이 개인정보 보호와 관련된 강화 조치를 주요 내용으로 하는 형태로 개정되고, 올해 1월 28일부터는 본격적으로 시행되어 대부분의 기업이 적용받게 되었다. 최근에는 이법률에 근거하여 고객정보 유출 사고에 책임이 있는 기업의 대표이사가 처음으로 형사 입건되는 사례도 발생하였다. 이처럼 정보통신망법의 개정 및 시행을 통해 최소한의 제도적인 장치는 마련되었다고 볼 수 있다.

하지만, 국내의 개인정보 유출 사고는 피해 규모가 해외 사례보다 상당히 심각하기 때문에 보다 강력한 규제준수 법안의 도입이 진행되고 있다. 미국의 Sarbanes-Oxley(SOX)법안처럼 모든 산업 부문의 기업들에게 보안 강화를 의무화하고 강력한 처벌을 할 수 있는 내용을 담고 있는 국내의 “개인정보보호법”이 국회에 제출되어 있다.

또한, 해외의 HIPAA, PCI/DSS, Gramm-Leach-Bliley 등과 같이 국내에서도 산업 부문별로 별도의 보안 관련 법안들이 준비중에 있다.

이처럼 개인정보보호를 위한 기업 규제준수 요구 수준은 갈수록 더욱 강화될 것임이 틀림없다.

<표 1> 국내 보안 유출 사고 사례(2008년부터 2010년 초까지)

 

데이터베이스 보안의 중요성

대규모 개인정보가 유출된 사고가 발생한 시스템의 운영 상황을 점검해 보면, 네트워크 및 서버 보안 등의 기존 보안 조치만으로는 이러한 사고를 막을 수 없다는 결론을 얻을 수 있다. 통계적으로 보더라도 이들 사고의 70% 이상이 방화벽 내부에서 발생하였고, 그중에서 90%가량이 정당한 권한을 가지고 있는 내부자에 의한 소행이었기 때문이다. 따라서 이러한 상황에서 데이터를 실제 저장 및 관리하는 데이터베이스 서버에 대한 별도의 보안 조치는 시급하고 중요한 문제이다.

개인정보보호를 위한 규제준수 법안에 기술되어 있는 조치 내용도 대부분 암호화, 접근제어, 감사와 같은 데이터베이스 보안 강화와 관련된 내용이다.

 

데이터베이스 보안 제품의 문제점

데이터베이스 보안 시스템을 구축하기 위해서는 먼저, 많은 제품을 검토하고 그 가운데에서 적합한 제품을 선정하는 일이 중요하다.

하지만, 현재 대다수의 고객이 이 과정을 올바르게 수행하지 못하고 있다. 따라서 본 기사를 통해 그동안 고객들에게 정확하게 전달되지 못했던 데이터베이스 보안 제품의 문제점들을 파악할 기회를 제공하고자 한다.

 

암호화

타사 암호화 제품의 문제점을 분석하기 위해서 암호화 수행 방식을 살펴보자. 먼저, <그림 1>과 같이 암복호화 API를 응용 프로그램 소스 코드에 적용하는 API 방식이 있다. 이 방식을 위해서는 먼저 암호화된 내용을 수용하기 위해 더 긴 길이의 컬럼으로 구조를 변경해야 한다. 그리고 일부 SQL문장의 로직과 성능에 문제가 발생할 수도 있기 때문에 응용 프로그램에서 사용하고 있는 모든 SQL문장을 사전에 조사해야 되고 그 결과로 SQL수정 등의 작업이 발생하기도 한다.

이처럼 API방식의 암호화는 응용 프로그램 소스 코드에서의 작업을 필요로 하기 때문에 많은 시간이 소요된다.(6개월에 걸쳐 4,000여 개의 프로그램을 수정하면서 20억의 예산이 소요된 사례가 있음) 이번에는 트리거(Trigger)가 암복호화 API를 호출해 자동 암호화를 수행하는<그림 2>와 같은 Plug-in방식이 있다.

데이터베이스 서버에 암복호화 API와 트리거를 생성하기 때문에 이를 Plug-in방식이라 부른다. 이 방식은 트리거를 이용해 자동 암호화를 하도록 설계되어 있지만, 트리거는 실제 INSERT, DELETE, UPDATE에 대해서만 동작한다. 따라서, SELECT에 대해서는 이미 암복호화 작업이 포함된 정의의 뷰(View)를 도입해야 된다.

결국, 최초 원본 테이블 대비 많은 구조 변경이 발생한다. 이러한 구조 변경은SQL기능 제약을 유발하는 문제점이 있다. 또한, 대량의 데이터 작업 시에 레코드 단위로 암호화를 위한 트리거가 동작하기 때문에 심각한 성능 저하가 발생한다. Plug-in제품들은 이와 같은 기능 제약과 성능 저하 문제를 위해 SQL 재작성, 수정 및 튜닝등의 과정을 필수적으로 수행한다. SQL문장이 응용 프로그램 소스 코드에 대부분 포함되어 있기 때문에, SQL문장에 대한 작업은 곧 응용 프로그램 수정을 의미한다.

그럼에도 불구하고, Plug-in제품이 응용 프로그램 수정을 유발하지 않는다고 주장하는 것은 잘못된 것인 만큼 고객들의 주의가 필요하다.

타사 암호화 제품이 제공하는 이러한 두 가지 방식은 많은 문제점들을 안고 있다. 각각의 내용을 살펴보자.

<그림 1> API 방식의 암호화

<그림 2> Plug-in방식의 암호화

심각한 성능 저하

트리거에 의존하는 Plug-in방식의 경우, 특정 암호화 벤치마크테스트(BMT) 과정에서 최대 850%의 오버헤드를 유발하는 것으로 측정된 바 있다. 예를 들어, 1시간이 걸리던 배치 업무가 8시간 반이 소요된다는 의미이다. 이 같은 심각한 성능 저하는 일 별 배치 처리와 같은 자동화 업무의 근간을 흔드는 것이다. 따라서, 반드시 검토 대상인 암호화 제품의 성능 오버헤드를 사전에 측정해 보아야 한다.

기능 제약 발생

타사 암호화 제품은 Update가 가능한 뷰를 사용하고 Domain Index라는 기능을 이용해 비표준 전용 인덱스를 구현해 사용하고 있는데, 이럴 경우 <표 2>와 같은
기능 및 성능상의 제약이 발생한다.

응용 프로그램 변경 필요

응용 프로그램 변경이 발생하는지의 여부는 암호화 적용을 위한 중요한 사전 고려 사항이다. 앞서 타사 암호화 제품의 두 가지 방식은 모두 응응 프로그램 변경이 반드시 필요함을 설명한 바 있다. 하지만 많은 고객은 응용 프로그램 수정이 전혀 불가능한 상황임에도 불구하고 이러한 상황을 지원하지 못하는 API방식 혹은 Plug-in방식을 검토하는 경우가 있다. <그림 3>을 통해 자세히 설명해 보자. 그림에서 X 축은 프로젝트의 단계를 나타내고, Y축은 도입의 형태를 나타낸다.

이때, 암호화 적용을 고민하고 있는 고객 응용 프로그램 유형은 대부분 C1혹은 C2에 해당하는 경우가 많다. 다시 말해, 외주 개발을 한 뒤 유지 보수가 만료되어 사소한 수정이 필요하더라도 재계약을 통해 다시 아웃소싱을 해야 되는 상황(C1), 자체 개발을 하였지만 최초 개발자의 투입이 불가능한 상황(C2)이 가장 많이 볼 수 있는 유형이다. 거듭 강조하지만 이런 경우의 고객들은 API방식 혹은 Plug-in방식의 암호화 제품을 검토해서는 안된다. 결론적으로 오직 커널 방식의 자동화된 암호화 방식만이 응용 프로그램 변경이 필요 없는 해결책임을 말하고 싶다.

인덱스 암호화 방식의 안정성 문제

암호화의 기본 원리 중 하나는 ‘암호화 전의 값이 가지고 있던 대소 관계까지도 없어진다.’는 것이다. 이 사실 때문에 암호화 컬럼 값에 인덱스가 생성되어 있어도 범위 검색(Range Scan) Query에 대해서는 인덱스를 이용하지 못하고 부득이 전체 검색(Full Scan)하는 문제가 있었다.(인덱스 검색을 위해서는 대소 비교가 가능해야 한다.) 이 부분을 극복하고자 일부 암호화 제품들은별도의 인덱스 방안을 고안해 냈다.(자세한 내용은 관련 제품의 특허 출원 내용을 특허청 홈페이지를 통해 다운로드 받아 확인할 수 있다.)

하지만, 문제는 이들 제품이 인덱스 생성 과정에서 재 암호화라는 단계를 통해 기존의 암호화 방식이 아니라 새롭게 고안해 낸암호화 알고리즘을 적용해 대소비교가 가능하도록 했다는 점이다. 그러나, 암호화의 원리를 떠올린다면 대소비교가 가능한 암호화 결과라는 것은 모순이다. 상식적인 얘기지만 대소비교를 통해 정보가 역으로 추론될 수 있는 위험성이 존재한다. 또한, 이러한 암호화 알고리즘은 국내외에서 전혀 검증되지 않았다는 점을 분명히 밝히고 싶다. 데이터 파일에 적용되는 암호화 알고리즘뿐만 아니라 인덱스에 적용하는 알고리즘 모두 객관적으로 검증된 것이 사용되어야 한다. 그렇지 않다면 안전한 암호화 알고리즘을 사용하도록 한 정보통신망법의 규정에 심각한 결격사유가 된다.

<표 2> 타사 암호화 제품의 기능 및 성능 제약

<그림 3> 응용 프로그램 유형별 적용 가능한 암호화 방식

 

접근제어방식

타사 접근제어 제품의 문제점을 분석하기 위해서 이들이 제공하는 접근제어 방식을 살펴보아야 한다. 먼저, <그림 4>에 나타난 것과 같이 스니핑(Sniffing) 방식이 있다. 데이터베이스 서버로 전달되는 SQL트래픽을 별도의 보안 서버에서 모니터링하면서 문제가 되는 SQL작업이 있으면 Kill Session 등의 수단으로 해당 세션을 강제 종료하는 방법으로 접근제어 기능을 수행한다. 하지만, 이러한 접근제어가 결국 SQL레벨이 아니라 세션 레벨로 동작한다는 점과 모니터링을 위해 별도의 네트워크 Tap장비가 필요한 단점이 있다. 무엇보다 현재 시장에서 요구하는 접근제어의 많은 기능이 스니핑 방식만으로는 불가하다는 한계를 가지고 있다.

스니핑 방식 이후, 보다 적극적인 접근제어 동작을 위해 게이트웨이(Gateway) 방식이 도입되었다. <그림 5>와 같이 별도의 보안서버로 모든 SQL트래픽을 전달받아 분석한 뒤에 문제가 없을 경우에만 데이터베이스 서버로 전달하는 방식이다. 이 방식을 통해 문제가 되는 SQL작업이 원천적으로 데이터베이스 서버로 전달되지 않도록 할 수 있지만, 게이트웨이 방식을 지원하는 대부분의 제품은 모든 SQL트래픽을 받아 처리하면서 발생하는 부하를 제대로 감당하지 못하는 문제가 있었다.

마지막으로, 스니핑과 게이트웨이 방식의 문제점을 극복하기 위해 두 가지 방식을 혼합한 <그림 6>과 같은 하이브리드(Hybrid) 방식이 현재 접근제어 방식의 주류를 이루고 있다. 응용 프로그램으로부터 전달되는 SQL트래픽은 일단 데이터베이스 서버로 전달하고 관련 내역은 스니핑을 통해 보안 서버에서 감사만 수행하고, 일반 사용자들의 데이터베이스 접속과 SQL요청 작업은 모두 보안서버에서 검사한 뒤에 문제가 없을 경우에만 전달하는 방식이다. 이를 통해 주로 문제가 되는 일반 사용자들의 세션에 대한 접근제어 기능은 강화하고 과부하는 줄이는 효과를 얻을 수 있다.

타사의 접근제어 제품들은 대부분 스니핑 방식에서 출발하여 게이트웨이 방식을 지원하기 시작했고, 나중에는 하이브리드 방식을 표방하는 순서로 옮겨왔다. 이제까지 살펴본 접근제어 방식들은 나름의 노력에도 불구하고 여전히 치명적인문제점을 안고 있다. 그 내용을 지금부터 하나하나 설명하고자 한다.

우회 접근을 통한 정보 유출의 위험성 존재

타사의 접근제어 제품은 데이터베이스 서버 외부에서 접근제어 기능을 수행한다. 결국, 접근 차단 대상 테이블 정보를 데이터베이스 서버 외부에서 목록으로 관리하면서 SQL을 검사할 때 살펴보는 방식이다. 하지만, <그림 7>에 나타난 상황과 같이 아무리 접근 차단 대상 테이블을 관리해도 데이터베이스 서버에서 해당 테이블에 대한 뷰(View), 동의어(Synonym), PL/SQL, Dynamic SQL 등의 우회적인 수단을 만든 뒤 접근을 시도하면 외부 접근제어 제품은 차단 대상 목록에 포함되어 있지 않기 때문에 이들 접근을 통제하지 못하고 모두 통과시킨다. 이처럼 간단한 유출 시도로 무력화될 수 있는 치명적인 단점이 존재하는 것이다.

로컬 접근에 대한 통제 불가

또한 Telnet으로 데이터베이스 서버에 먼저 접속한 이후에 SQLPLUS를 실행하는 등의 로컬 접속을 기본적으로 통제하지 못한다. 이러한 문제 때문에 SQLPLUS실행 파일을 래핑(Wrapping)한 모듈을 제공해 실제 사용자들은 모르고 동일한 SQLPLUS프로그램을 실행한 것처럼 사용하지만 래핑 모듈에 추가된 감사 기능을 통해 작업 내용을 기록할 수 있다. 결국 <그림 8>과 같이 로컬 접근 시에는 접근제어 기능을 수행하는 것이 아니라 감사기능으로 대응하고 있는 것이다. 로컬 접근을 통한 정보 유출이 빈번히 발생하는것을 감안하면 이 역시 심각한 문제라고 할 수 있다.

이중화로 인한 추가 비용 발생

타사의 접근제어 제품은 시스템 구성상 보안 서버가 설치될 별도의 하드웨어와 네트워크 Tap 장비 등이 필요하다. 소프트웨어 초기 도입 비용이 비교적 저렴하기 때문에 이러한 추가적인 하드웨어 비용을 감수하는 경우가 있으나 <그림 9> 에서 보듯이 모든 시스템 구성 요소들이 이중화되어야 되는 상황을 감안하면 비용은 예상외로 상당히 증가할 수 있다.

여기까지 타사 데이터베이스 보안 제품의 주요 문제점을 살펴보았다. 이제는 <표 3>과 같이 신문 등을 통해 접할 수 있는 고객들의 도입 피해 사례를 보고 구체적으로 어떤 문제점들이 발생하였을지 짐작할 수 있는 정보가 생겼을 것으로 기대한다.

<그림 4> 스니핑 방식의 접근 제어

<그림 5> 게이트웨이 방식의 접근 제어

<그림 6> 하이브리드 방식의 접근 제어

 

오라클 데이터베이스 보안 솔루션

이번에는 이러한 많은 문제점을 오라클 데이터베이스 보안 솔루션을 통해 어떻게 해결할 수 있는지를 설명할 순서이다. 결론적으로 타사 제품들의 문제점은 데이터베이스 내부에서 보안 기능을 수행하지 못하기 때문에 발생한 것이다. 따라서, 데이터베이스 내부, 즉 커널에서 보안 기능을 수행함으로써 지금까지 언급된 모든 문제를 극복할 수 있다. 그러므로 오라클이 데이터베이스 보안과 관련해 고객에게 전달하고 싶은 메시지는 ‘데이터를 커널에서 안전히 보호하라(Secure Data at the Source)’이다.

그럼, 오라클이 제공하는 커널 방식의 암호화를 살펴보자. <그림 10>에서 볼 수 있듯이, 디스크에 있는 물리적인 데이터파일과 작업 메모리 공간(SGA) 사이에서 입출력을 담당하는 백그라운드 프로세스(서버 프로세스, DBWR)들이 자동으로 암복호화를 담당한다. 응용 프로그램은 기존과 동일한 테이블 규격에 접근하는 것이다. 그러므로 응용 프로그램 변경은 전혀 불필요하다. 오직 커널 방식을 통해서만 응용 프로그램 변경이 없는 암호화가 가능하다. 그리고, 암복호화 과정이 내부 동작에 포함되어 있어 성능 오버헤드를 최소화할 수 있다. 많은 성능 벤치마크 테스트 과정에서 비교할 수 없는 차이로 가장 안정적인 성능을 나타내는 것으로 이미 입증되었다. 또한, 오라클의 암호화 방식은 일체의 기능 제약을 발생시키지 않는다. 10g 암호화로 인해 발생하였던 일부 제약도 11g에서는 모두해결되어 현재는 암호화로 인한 기능 제약이 전혀 없다.

<그림 7> 하이브리드 방식의 접근 제어

<그림 8> 로컬 접근에 대한 통제 불가

<그림 9> 이중화로 인한 추가 비용 발생

<표 3> 데이터베이스 보안 제품 도입 피해 사례

<그림 10> 커널 방식의 암호화

오라클이 제공하는 접근제어는 <그림 11>에서 보듯이 커널에서 기존 SQL처리 과정의 구문분석 단계에서 추가로 기능이 수행되는 방식이다. 데이터베이스 외부에서 별도의 구분된 과정으로 접근제어 기능이 수행되는 방식에 비해 상당히 오버헤드를 낮출 수 있다. 그리고 오라클 접근제어 솔루션이 제공하는 중요한 점은 특정 객체를 접근제어 대상으로 설정했을 때에는 어떠한 우회접근 수단을 만들어 유출을 시도해도 동일하게 차단할 수 있다는 것이다. 객체 간의 관계를 모두 분석해서 의미상으로 차단하고 있기 때문에 가능한 것이다. 또한 원격 접근, 로컬 접근의 구분 없이 모든 접근에 대해 동일한 접근제어 기능이 적용된다. 그리고 데이터베이스 내부 커널에 추가적으로 설치되어 운영되는 방식이므로 별도의 하드웨어 자체가 불필요하다.

지금 고객에게 필요한 것은 올바른 데이터베이스 보안 제품을 선택하기 위한 명확한 판단 기준이다. 본 기사를 통해 제시한 타사 제품들의 문제점을 심각하게 받아들이고 이를 판단 기준으로 삼기를 바란다.(이러한 문제점들을 알고도 잘못 도입하는 우를 범해서는 안된다.) 그리고 타사 제품의 문제점들이 데이터베이스 내부에서 보안 기능을 수행하지 못해 발생한 것들임을 알게 되었다면, 커널 방식으로 동작하는 데이터베이스 보안 솔루션의 접근 방법이 유일한 해결 방안임도 잊지 말아야 한다.

오라클이 제시하는 데이터베이스 보안 기술이 얼마나 체계적이고 합리적인 방안인가를 설명하기 위해, Forrester에서 발표한 [2010 엔터프라이즈 데이터베이스 보안 전략]을 인용하고자 한다. <그림 12>에서와 같이 이상적인 데이터베이스 보안 구축을 위해서는 본 기사의 서두에서도 주로 다루었지만 하단부에 나타나 있는 규제준수 법안(Compliance) 이슈를 잘 이해해야 한다. 그리고 사전 차단을 위한 Preventive한 수단을 갖추어야 하고, 사후 검증을 위한 Detection메커니즘을 확보해야 한다. 오라클은 Preventive한 수단으로 암호화(Advanced Security, Data Masking, Secure Backup), 접근제어(Database Vault, Label Security) 관련 제품들을 제공하고 있고, Detection수단으로 감사(Audit Vault, Total Recall, Configuration Management) 제품들을 제공하고 있다. <그림 13>에 나타나 있듯이, 각각의 이슈에 대해 통찰력 있는 제품들로 오라클 데이터베이스 보안 솔루 션은 구성되어 있다. Forrester보고서에서 마지막으로 중요하게 언급하고 싶은 부분은 바로 좌측 상단의 Foundation요소이다. 이것이야말로 데이터베이스 보안의 근간을 이루는 기본적인 인프라 요소일 것이다. 우리는 그것이 오라클 데이터베이스에서 제공하는 기본적인 계정 및 권한 관리, 역할 체계, 지속적인 패치 서비스 제공 등의 형태일 것으로 본다. 이러한 Foundation요소와 함께 추가적인 제품 도입을 통해 보강되어야 할 Preventive, Detection요소들이 조화롭게 운영 되어야만 이상적인 데이터베이스 보안 구축이 가능하다는 것이 Forrester보고서의 핵심 내용이다. 자칫 데이터베이스 보안이 이슈가 되는 최근의 상황에서 이러한 Foundation요소들과의 호흡을 중요하게 고려하지 못하고, 별도의 새로운 단일 제품만으 로 모든 문제를 해결할 수 있다고 접근하는 제품과 회사를 경계해야 할 것이다.

본 기사에서 제시한 타사의 문제점들과 피해 사례들은 모두 직접 고객들로부터 전해 듣거나 신문을 통해 확인한 객관적인 사실들이었다. 이 내용을 전달하는 목적은 고객의 올바른 선택을 위한 정보를 주기 위함이었다. 데이터베이스 보안 구축이라는 당면 과제로 고민에 빠져 있는 많은 고객에게 도움이 되었기를 바란다.

<그림 11> 커널 방식의 접근제어

<그림 12> 엔터프라이즈 데이터베이스 보안 시스템 구축 전략

<그림 13> 오라클 데이터베이스 보안 솔루션 구성


출처 : ORACLE KOREA / DBguide.net


Trackback 0 Comment 0
2009. 1. 14. 14:50

Linux 이중화 (High-Availability) 구성 방법

728x90

1. Heartbeat RPM 다운
http://ftp.daum.net/centos/5/extras/i386/RPMS/ 에서 (또는 x86_64)

heartbeat-2.1.3-3.el5.centos.i386.rpm
heartbeat-gui-2.1.3-3.el5.centos.i386.rpm
heartbeat-ldirectord-2.1.3-3.el5.centos.i386.rpm
heartbeat-pils-2.1.3-3.el5.centos.i386.rpm
heartbeat-stonith-2.1.3-3.el5.centos.i386.rpm

2. libnet RPM 다운
http://ftp.daum.net/centos/5/extras/i386/RPMS/ 에서 (또는 x86_64)

libnet-1.1.2.1-2.rf.i386.rpm

3. RPM 설치
rpm -ivh heartbeat-pils-2.1.3-3.el5.centos.i386.rpm
rpm -ivh heartbeat-stonith-2.1.3-3.el5.centos.i386.rpm
rpm -ivh --nodeps heartbeat-ldirectord-2.1.3-3.el5.centos.i386.rpm
rpm -ivh heartbeat-gui-2.1.3-3.el5.centos.i386.rpm
rpm -ivh heartbeat-2.1.3-3.el5.centos.i386.rpm
rpm -ivh heartbeat-2.1.3-3.el5.centos.i386.rpm (처음 설치 시 error가 나는데 다시 하면 정상설치됨)

rpm -ivh libnet-1.1.2.1-2.rf.i386.rpm

4. heartbeat 설정 복사

/usr/share/doc/heartbeat-2.1.3/ 에 있는
ha.cf, haresources, authkeys 파일을
/etc/ha.d/로 복사한다.

cp /usr/share/doc/heartbeat-2.1.3/ha.cf /etc/ha.d/
cp /usr/share/doc/heartbeat-2.1.3/haresources /etc/ha.d/
cp /usr/share/doc/heartbeat-2.1.3/authkeys /etc/ha.d/

5. ha.cf 파일을 다음과 같이 변경한다.

debugfile /var/log/ha-debug #디버그 메세지를 기록할 파일 설정
logfile /var/log/ha-log  #그 외의 메시지를 기록할 파일 설정
logfacility     local0  
keepalive 2    #두 노드간에 얼마나 자주 heartbeat를 주고받을 것인가를 설정(sec)
deadtime 30   #서버가 죽었다고 판단 하는 시간 설정(sec)
initdead 120   #서버 시작후 대기 시간(sec)
udpport 694   #heartbeat 통신포트
bcast   eth0   #heartbeat 를 보낼 NIC 설정(bond가 되는지는 확인필요)        
auto_failback on  #FailOver를 사용할지 여부
node WAS1    #마스터 서버 nodename
node WAS2    #슬레이브 서버 nodename (순서가 중요하다.)
uuidfrom nodename #설치CD등으로 까는경우 uuid가 중복되서 이상해지는 경우가 생기는 것을 nodename으로 결정하도록

6. haresources 설정

nodename 대표IP/subnetbit/broadcastIP 서비스이름
이떄 nodename은 master의 nodename을 기록한다.

ex) WAS1 192.168.0.222/24/192.168.0.255 httpd smb

7. authkyes 설정

auth 1
#1 crc
#2 sha1 HI!
1 md5 Hello!

(아마 암호화 방법과 Hello! 부분을 이중화 하는 서버가 같게 설정하면 되는 것 같다)

chmod 600 authkeys (해주지 않으면 heartbeat 서비스 실행시 오류가 난다)

8. hosts 설정

/etc/hosts 파일을 열고 이중화하는 서버의 IP와 nodename 을 기록

192.168.0.200 WAS1
192.168.0.201 WAS2

9. hostname 설정

/etc/sysconfig/network 에서 HOSTNAME 부분을 각각의 서버에 맞게 설정한다.

10. 실행할 서비스 등록

실행할 서비스를 /etc/ha.d/resource.d/에 링크를 건다.
resource.d에 링크를 걸어줄 수 있는 것은 service 형태이거나
스크립트로 start, stop으로 실행/중지를 할 수 있는 형태인 경우에만 가능하다.

ex) ln -s /etc/rc.d/init.d/httpd /etc/ha.d/resource.d/httpd

11. 서비스 등록

chkconfig --add heartbeat

12. reboot 으로 확인

참고사이트 : www.linux-ha.org

출처 : http://edica.tistory.com/

Trackback 11 Comment 1
  1. 2009.02.28 14:30 address edit & del reply

    비밀댓글입니다

2009. 1. 14. 14:49

게이트웨이(Gateway)의 이중화 VRRP/HSRP

728x90


HSRP(Hot Standby Routing Protocol)과 VRRP( Virtual Router Redundancy Protocol)

이름만 다를 뿐 하는 일이나 동작원리는 거의 같습니다.

물론 비슷한 것으로 익스트림의 ESRP가 있지만...배제하겠습니다.

 

이정도 강의를 읽으실 회원님들이시면..클라이언트가 같은 네트워크에선 상관이 없지만 다른 네트워크로 갈 때는 반드시 게이트웨이를 거쳐야 한다는 것을 아실 겁니다.

모르시면 강좌 "스위칭 라우팅" 참조하시길...

 

자, 위의 구성을 보죠..백본 2대..여기에 VLAN 2개올리고 IP라우팅을 합니다. 그리고 하단에 L2스위치가 보이구요, 하단에 PC 클라들이 보이죠

백본 2와 L2스위치로 가는 라인은 아마 Block이 걸릴 것입니다.  통신이 안되겠죠..

아직 Spaning tree를 이해못하셨다면 이전에 STP에 대한 강좌에 설명이 되어있습니다.

 

자, 10.10.10.X/24 네트워크에 대한 게이트웨이를 1이라 가정하면..백본 1이 죽으면 어떻게 될까요?

PC들은 10.10.10.X 네트워크의 리소스만 접근이 가능합니다.  다른 인터네트워크로는 접근을 할수가 없죠...왜냐하면 백본 1이 게이트웨이인데..게이트웨이가 없졌으니 라우팅을 할 수 없는 것이죠.

이래서 게이트웨이를 이중화 한것이 HSRP와 VRRP입니다.

HSRP는 시스코가 개발을 한것이고, 시스코 장비에만 올라갑니다.

VRRP는 IBM이 개발했고, 시스코를 포함한 모든 밴더에 올라가죠....표준안은 VRRP입니다.

 

만약, 경쟁입찰에서 다른 밴더 제품 못들어오게 하고 싶으시면 스펙에 "HSRP지원!!!!" 써 놓으시면

시스코 외엔 아무도 들어올 수 없습니다. ^^* (요러한 사항은 추후 RFP제작 이란 강좌를 다시 하겠습니다.)

 

HSRP나 VRRP를 설정하면 공통적인 것이 있습니다.  바로 Virtual IP를 생성 한다는 것이죠.

그리고 한넘은 Active, 한넘은 Standby가 됩니다.

 

다시 설명드리죠...백본 1의 IP는 10.10.10.1/24 백본 2의 IP는 10.10.10.2/24 그리고 VRRP설정시

Virtual IP는 10.10.10.254라고 가정하면, 두장비다 이 VIP로 동작을 합니다.

물론, 클라이언트에서 게이트웨이는 이 VIP인 10.10.10.254로 설정하죠..

 

백본 1은 10.10.10.254라는 IP를 가지고(자신의 아이피죠) 백본 2에 계속 hello를 보냅니다.

"나 살아있으니 알아서 죽어있어라~"  왜 일까요? 만약 백본 2도 10.10.10.254 VIP를 가동시키면

IP충돌이 나기 때문입니다.   백본 1이 죽을 경우...hello를 못받은 백본 2가 살아나서 다시 10.10.10.254로 라우팅을 계속해서 수행하게 됩니다.

 

이것이 게이트웨이의 이중화 입니다.



자, 이제 VRRP/HSRP가 어케 동작을 하는지 알아보죠...

실제 VRRP와 HSRP는 동작원리가 90%이상 같습니다.

HSRP는 시스코에서 나온 표준안이고 VRRP는 IBM에서 나왔습니다. RFP에는 VRRP가 먼저 등제되었습니다.

자, 위의 그림과 같이 세팅되었다고 치죠...각 백본에 VLAN을 두개 만들고 VRRP/HSRP그룹을 각각 1개씩 만들었습니다.

이 VRRP/HSRP에선 어떤 옵션을 선택할 수 있을까요?

 

1. VIP 당연하겠죠?  게이트웨이 서비스할 IP가 있어야 겠죠?

2. Priority  0~255설정입니다. 0은 VRRP에서만 적용됩니다. 

   두대중 어느놈이 ACtive인지 Standby인지 정합니다.  높은넘이 Active입니다.

3. Preempt  이건...장애 후에 다시 Priority가 높은 넘이 Active가져갈지 말지 정하는 것이죠..

   이건 다시 설명드리겠습니다.

 

각 장비는 멀티케스트로 자기의 정보를 날립니다.  이걸 Hello 패킷이라 부릅니다.

1번은 이렇게 말하겠죠..

"내 Priority는 200이구..내 VRRP ID는 0이다..."

이걸들은 2번 백본은 "내 priority는 100이구 내 VRRP ID는 0 이다"

2번스위치는 1번이 priority가 더 높다는 것을 알죠..그래서 standby상태로 있습니다.

옵션에서 정할 수 있지만 보통 hello는 3초마다 뿌립니다. 만약 백본 #1이 죽었다면...백본 #2는 그걸 어떻게 알까요?  3초후에 백본 #1로부터 hello가 안날라오겠죠?  그럼 백본 #2가 바로 active로 바뀔까요?  아닙니다.   백본#1이 뿌린 hello를 못받았을 수도 있다는 생각을 합니다.  그래서 hello의 3배를 기다립니다.(RIP과 같죠?)   이걸 hold time이라 합니다.

10초간 기둘려도 hello가 안날라오면..."아..확실히 뒤졌구나" 라고 백본#2는 생각하고 바로 Active로 전환하는 것입니다.

 

자..장애 복구 후 백본 #1이 살았습니다.  그럼 어케될까요?  만약 preempt가 enable되어있다면

백본 #1이 priority가 더 높기 때문에 백본 #1이 active로 다시 바뀝니다.

preempt가 disable이라면 priority가 더 높은 백본#1이 살더라도 계속 백본#2가 active가 됩니다.

 

이제 VIP이야기를 해볼까요?

백본 #1,#2는 각각 VIP를 가지고 있습니다.  두넘의 MAC은 어떨까요?  각자 만들었으니 비록 IP는 같아도 MAC도 같을까요?   같다면 서로 어떻게 맞춘것일까요?

 

먼저, MAC은 같아야 합니다.!!! 왜냐구요?  이해를 못하셨다면 기존 스위치강좌,스위치&허브 강좌 다시 읽으십시요...

예를 들어 백본#1의 VIP MAC이 111111:111111 이고 백본#2의 VIP MAC이 222222:222222라면

클라이언트의 ARP테이블엔 192.168.10.254 111111:111111라고 기억이 될겁니다.

백본#1이 장애가 났습니다. 그럼 백본#2가 active가 됩니다.

그래도 클라이언트는 통신이 안됩니다.  IP는 그대로가 되었지만 MAC이 다릅니다.

그래서 통신이 안되는 것이죠..백본에서 클라이언트에게 일일이 ping을 쏴주거나 클라이언트의 ARP테이블이 지워질때까지 통신은 안됩니다.  그래서 MAC도 같아야 합니다.

 

HSRP는 00:00:0C:07:AC:00 을 사용합니다.

VRRP는 00:00:5E:00:01:00을 사용합니다.

맨 앞의 00의미는 아시죠? 앞이 0이면..멀티케스트란 이야기입니다. ^^*

이것은 룰입니다.  따라서 VRRP/HSRP표준을 따르면 각 VIP를 생성할때마다 반드시 저 MAC으로 자동생성됩니다.  그래서 두 장비간에 MAC이 같아지는 것이죠..

한 VLAN안에 네트워크가 여러개일 경우는 어케할까요? 흔히 멀티넷이라 하죠..시스코에서는 세컨드리 아이피라 합니다.

VIP 1 00:00:5E:00:01:00

VIP 2 00:00:5E:00:01:01

VIP 3 00:00:5E:00:01:02  이런식으로 MAC을 생성합니다.

 

위의 그림을 다시 보죠..

VIP1 192.168.10.254 00:00:5E:00:01:00

VIP 2 192.168.20.254 00:00:5E:00:01:00   자, 각각 VLAN의 0번 id를 썼기에 MAC이 같습니다!!!

 

네떡에 문제가 생기겠죠?

아닙니다...안생깁니다.  왜냐구여? VLAN이 다르잖아요...

따라서 클라이언트는 다른 네트워크에 같은 MAC이 있다는 것을 모릅니다.

전에 말씀드렸듯이 ARP는 라우팅이 되질 않거등요...자신의 네트워크에서만 MAC을 스케닝 합니다.


Trackback 0 Comment 3
  1. 네떡초보 2015.10.22 13:30 address edit & del reply

    자세한 설명 감사합니다! 이해가 바로 되네요 ㅎㅎ

  2. rcreer 2016.10.30 02:43 address edit & del reply

    백본이 stanby 포함해서 ip를 3개나 갖는 것이 너무 의문이였는데 감사합니다!

  3. rcreer 2016.10.30 03:01 address edit & del reply

    궁금한 점이 생겨 질문 남깁니다~ 만약 vlan 1 이 192.168.25.x/24이고 vlan 2 가 192.168.26.x/24 이라 한다면 두 vlan 이 모두 백본에 접속이 가능하게 하려면 192.168.25.x/25 의 영역으로 ip 를 할당해 주면 되나요? 아니면 각 vlan 별로 각각 다른 여러개의 ip 를 갖게 되나요? 그것도 아니라면 switch 에서 디폴트 게이트웨이를 이용하여 백본까지 연결을 시키는 건가요?