Cluster Suite 개요

Cluster management manages cluster quorum and cluster membership. CMAN (an abbreviation for cluster manager) performs cluster management in Red Hat Cluster Suite for Red Hat Enterprise Linux 5. CMAN is a distributed cluster manager and runs in each cluster node; cluster management is distributed across all nodes in the cluster (refer to 그림 1.2. “CMAN/DLM Overview”).

CMAN keeps track of cluster quorum by monitoring the count of cluster nodes. If more than half the nodes are active, the cluster has quorum. If half the nodes (or fewer) are active, the cluster does not have quorum, and all cluster activity is stopped. Cluster quorum prevents the occurrence of a "split-brain" condition — a condition where two instances of the same cluster are running. A split-brain condition would allow each cluster instance to access cluster resources without knowledge of the other cluster instance, resulting in corrupted cluster integrity.

정족수 (quorum)는 이더넷을 통한 클러스터 노드 사이에서의 메세지 통신에 의해 결정됩니다. 다른 방법으로 정족수는 이더넷을 통한 메세지 통신과 정족수 디스크를 통한 메세지 통신의 결합으로 결정될 수 있습니다. 이더넷을 통한 정족수의 경우, 정족수는 플러스 1을 선택한 노드의 50 퍼센트로 구성되며, 정족수 디스크를 통한 정속수의 경우, 정족수는 사용자 지정 상태로 구성됩니다.

CMAN은 다른 클러스터 노드에서의 메세지를 모니터링하여 멤버쉽을 파악합니다. 클러스터 맴버쉽이 변경될 때 클러스터 관리자는 다른 인프라 구성 요소를 확인하고 적절한 작업을 실행합니다. 예를 들어, 노드 A가 클러스터에 연결되어 노드 B와 C가 마운트된 GFS 파일 시스템을 마운트할 경우, GFS 파일 시스템을 이용하기 위해 노드 A에 추가 저널 및 잠금 관리 기능을 필요로 합니다. 클러스터 노드가 지정된 시간 안에 메세지를 전송하지 않을 경우, 클러스터 관리자는 클러스터에서 노드를 삭제하고 멤버가 아닌 노드가 있는 다른 클러스터 인프라 구성 요소와 통신합니다. 다른 클러스터 인프라 구성 요소는 더이상 클러스터 멤버가 아닌 노드에 대해 어떤 작업을 실행할 지를 결정합니다. 예를 들어, Fencing으로 멤버가 아닌 노드를 차단할 수 있습니다.

Lock management is a common cluster-infrastructure service that provides a mechanism for other cluster infrastructure components to synchronize their access to shared resources. In a Red Hat cluster, DLM (Distributed Lock Manager) is the lock manager. As implied in its name, DLM is a distributed lock manager and runs in each cluster node; lock management is distributed across all nodes in the cluster (refer to 그림 1.2. “CMAN/DLM Overview”). GFS and CLVM use locks from the lock manager. GFS uses locks from the lock manager to synchronize access to file system metadata (on shared storage). CLVM uses locks from the lock manager to synchronize updates to LVM volumes and volume groups (also on shared storage).

Fencing is the disconnection of a node from the cluster's shared storage. Fencing cuts off I/O from shared storage, thus ensuring data integrity. The cluster infrastructure performs fencing through the fence daemon, fenced.

CMAN이 노드에 장애가 발생했다고 판단하면, 장애가 발생한 노드가 있는 다른 클러스터 인프라 구성 요소와 통신합니다. 장애 발생 통보시 fenced는 장애 발생 노드를 차단합니다. 다른 클러스터 인프라 구성 요소는 어떤 작업을 취할 지를 결정합니다 — 즉, 노드에 필요한 복구 작업을 실행합니다. 예를 들어, 노드 장애 발생시 fenced가 장애가 발생한 노드에 fencing 작업을 완료할 때까지 DLM 및 GFS는 작업을 일시 중지합니다. 장애 발생한 노드의 fencing 작업이 완료되면, DLM 및 GFS는 복구 작업을 실행합니다. DLM은 장애 발생 노드의 잠금 기능을 해재하고, GFS는 장애 발생 노드의 저널을 복구합니다.

fencing 프로그램은 클러스터 설정 파일에서 어떤 fencing 방법을 사용할 지를 결정합니다. 클러스터 설정 파일에서는 fencing 에이전트 및 fencing 장치라는 두가지 주요 fencing 방법이 있습니다: fencing 프로그램은 클러스터 설정 파일에 지정된 fencing 에이전트로 호출합니다. 다음으로 fencing 에이전트는 fencing 장치를 통해 노드를 차단합니다. fencing 작업이 완료되면 fencing 프로그램은 클러스터 관리자에게 알립니다.

Red Hat Cluster Suite에서는 다양한 fencing 방법을 제공합니다:

그림 1.3. “Power Fencing Example” shows an example of power fencing. In the example, the fencing program in node A causes the power controller to power off node D. 그림 1.4. “Fibre Channel Switch Fencing Example” shows an example of Fibre Channel switch fencing. In the example, the fencing program in node A causes the Fibre Channel switch to disable the port for node D, disconnecting node D from storage.

fencing 방법은 클러스터에 있는 각각의 노드에 대한 fencing 방법 이름, fencing 에이전트, fencing 장치를 지정하기 위한 클러스터 설정 파일의 편집으로 구성되어 있습니다.

The way in which a fencing method is specified depends on if a node has either dual power supplies or multiple paths to storage. If a node has dual power supplies, then the fencing method for the node must specify at least two fencing devices — one fencing device for each power supply (refer to 그림 1.5. “Fencing a Node with Dual Power Supplies”). Similarly, if a node has multiple paths to Fibre Channel storage, then the fencing method for the node must specify one fencing device for each path to Fibre Channel storage. For example, if a node has two paths to Fibre Channel storage, the fencing method should specify two fencing devices — one for each path to Fibre Channel storage (refer to 그림 1.6. “Fencing a Node with Dual Fibre Channel Connections”).

하나의 fencing 방법이나 또는 여러 개의 fencing 방법을 사용하여 노드를 설정할 수 있습니다. 하나의 fencing 방법으로 노드를 설정한 경우, 이 방법만으로 노드를 fencing할 수 있습니다. 여러 fencing 방법으로 노드를 설정한 경우, 클러스터 설정 파일에서 지정된 fencing 방법 순서에 따라 하나의 fencing 방법에서 다른 방법으로 캐스캐이드 (cascade) 됩니다. 노드에 문제가 있을 경우, 클러스터 설정 파일에서 설정한 첫번째 fencing 방법으로 노드가 차단됩니다. 첫번째 fencing 방법에 문제가 발생했을 경우 두번째로 설정된 fencing 방법이 사용됩니다. 아무 fencing 방법도 실행되지 않을 경우, fencing은 첫번째로 설정된 fencing 방법을 다시 실행하게 되며 노드에 fencing이 실행될 때까지 클러스터 설정 파일에 설정된 순서로 fencing 방법을 반복 실행하게 됩니다.

The Cluster Configuration System (CCS) manages the cluster configuration and provides configuration information to other cluster components in a Red Hat cluster. CCS runs in each cluster node and makes sure that the cluster configuration file in each cluster node is up to date. For example, if a cluster system administrator updates the configuration file in Node A, CCS propagates the update from Node A to the other nodes in the cluster (refer to 그림 1.7. “CCS Overview”).

Other cluster components (for example, CMAN) access configuration information from the configuration file through CCS (refer to 그림 1.7. “CCS Overview”).

클러스터 설정 파일 (/etc/cluster/cluster.conf)은 XML 파일로 다음과 같은 클러스터 특징이 설명되어 있습니다:

You can obtain the highest shared-file performance when applications access storage directly. The GFS SAN configuration in 그림 1.11. “GFS with a SAN” provides superior file performance for shared files and file systems. Linux applications run directly on cluster nodes using GFS. Without file protocols or storage servers to slow data access, performance is similar to individual Linux servers with directly connected storage; yet, each GFS application node has equal access to all data files. GFS supports over 300 GFS nodes.

Multiple Linux client applications on a LAN can share the same SAN-based data as shown in 그림 1.12. “GFS and GNBD with a SAN”. SAN block storage is presented to network clients as block storage devices by GNBD servers. From the perspective of a client application, storage is accessed as if it were directly attached to the server in which the application is running. Stored data is actually on the SAN. Storage devices and data can be equally shared by network client applications. File locking and sharing functions are handled by GFS for each network client.

그림 1.13. “직접 연결된 스토리지를 사용하는 GFS 및 GNBD” shows how Linux client applications can take advantage of an existing Ethernet topology to gain shared access to all block storage devices. Client data files and file systems can be shared with GFS on each client. Application failover can be fully automated with Red Hat Cluster Suite.

그림 1.20. “Two-Tier LVS Topology” shows a simple LVS configuration consisting of two tiers: LVS routers and real servers. The LVS-router tier consists of one active LVS router and one backup LVS router. The real-server tier consists of real servers connected to the private network. Each LVS router has two network interfaces: one connected to a public network (Internet) and one connected to a private network. A network interface connected to each network allows the LVS routers to regulate traffic between clients on the public network and the real servers on the private network. In 그림 1.20. “Two-Tier LVS Topology”, the active LVS router uses Network Address Translation (NAT) to direct traffic from the public network to real servers on the private network, which in turn provide services as requested. The real servers pass all public traffic through the active LVS router. From the perspective of clients on the public network, the LVS router appears as one entity.

LVS 라우터로 들어온 서비스 요청은 가상 IP 주소 또는 VIP에서 인식됩니다. 이는 공개적으로 라우팅할 수 있는 주소로 사이트의 관리자가 www.example.com와 같은 FQDN (fully-qualified domain name)으로 연관지어 하나 이상의 가상 서버로 지정합니다. ^[1] VIP 주소는 장애 조치를 하는 동안 하나의 LVS 라우터에서 다른 라우터로 이전시키게 되므로 해당 IP 주소로 현재 위치를 유지하게 됩니다. 이를 유동 IP 주소라고 합니다.

VIP 주소는 LVS 라우터를 공개 네트워크로 연결시키는 장치와 같은 것으로 알리아스될 수 있습니다. 예를 들어, eth0가 인터넷에 연결되어 있을 경우, 여러 가상 서버는 eth0:1로 알리아스될 수 있습니다. 다른 방법으로 각각의 가상 서버는 서비스마다 분리된 장치와 연관시킬 수 있습니다. 예를 들어, HTTP 소통량은 eth0:1에서 처리될 수 있으며, FTP 소통량은 eth0:2에서 처리될 수 있습니다.

한번에 하나의 LVS 라우터만이 활성화됩니다. 활성화된 LVS 라우터의 역할은 가상 IP 주소에서 실제 서버로 서비스 요청을 보내는 것입니다. 이는 여덟개의 로드 밸런싱 알고리즘 중 하나에 기반합니다:

또한, 활성화된 LVS 라우터는 send/expect 스크립트를 통해 실제 서버에 있는 특정 서비스의 전반적인 상태를 정적으로 모니터합니다. HTTPS나 SSL과 같은 정적인 데이터에 필요한 서비스의 상태를 점검하기 위해 외부에서 실행 가능하게 할 수 있습니다. 실제 서버에서의 서비스가 잘 작동하지 않을 경우, 활성화된 LVS 라우터는 서버가 정상적인 작동 상태로 돌아올 때 까지 실제 서버로의 작업 전송을 중단합니다.

백업 LVS 라우터는 대기 시스템의 역할을 실행합니다. 주기적으로 LVS 라우터는 주요 외부 공개 인터페이스, 장애 조치 상태, 개인 인터페이스를 통해 하트비트 메시지 (heartbeat message)를 교환합니다. 백업 LVS 라우터는 정해진 간격 내로 하트비트 메시지를 받지 못하면, 장애 조치를 초기화하고 활성화된 LVS 라우터의 역할을 실행합니다. 장애 조치가 진행되는 동안 백업 LVS 라우터는 ARP spoofing이라는 기술을 사용하여 장애가 발생한 라우터에 의해 VIP 주소를 전달 받게 됩니다. — 여기서 백업 LVS 라우터는 IP 패킷의 목적지를 장애가 발생한 노드로 지정했음을 알립니다. 장애가 발생한 노드가 정상으로 돌아오면, 백업 LVS 라우터는 다시 백업 역할을 실행하게 됩니다.

The simple, two-tier configuration in 그림 1.20. “Two-Tier LVS Topology” is suited best for clusters serving data that does not change very frequently — such as static web pages — because the individual real servers do not automatically synchronize data among themselves.

그림 1.21. “Three-Tier LVS Topology” shows a typical three-tier LVS configuration. In the example, the active LVS router routes the requests from the public network (Internet) to the second tier — real servers. Each real server then accesses a shared data source of a Red Hat cluster in the third tier over the private network.

토폴로지는 소통량이 많은 FTP 서버에 아주 적합합니다, 여기서 액세스할 수 있는 데이터는 중앙 고가용성 서버에 저장되어 있으며 내보내어진 NFS 디렉토리나 Samba 공유 디렉토리를 통해 각각의 실제 서버에 액세스할 수 있습니다. 이러한 토폴로지는 트랜잭션을 위한 중앙 고가용성 데이터베이스를 액세스하는 웹사이트에 사용할 것을 권장합니다. 또한, Red Hat 클러스터를 사용한 active-active 설정으로, 하나의 고가용성 클러스터를 설정하여 동시에 두가지 역할을 실행하게 할 수 있습니다.

NAT (Network Address Translation) 라우팅 또는 LVS를 사용한 직접 라우팅을 사용할 수 있습니다. 다음 부분에서는 NAT 라우팅과 LVS를 사용한 직접 라우팅에 대해 간략하게 설명합니다.

특정한 경우에는 로드 밸런스 알고리즘이 가장 적합한 서버에 요청을 보내는것 보다 동일한 실제 서버에 반복적으로 다시 연결하는 것이 클라이언트에게 더 좋을 수 있습니다. 예를 들어, 여러 화면의 웹 형식, 쿠키, SSL, FTP 연결일 경우에 그러합니다. 이러한 경우, 문맥을 유지하기 위해 트랜잭션이 같은 서버에 의해 처리되지 않는 한 클라이언트가 제대로 작업할 수 없게 됩니다. LVS는 지속성 (persistence) 및 방화벽 표시 기능 (firewall marks)이라는 두가지 다른 종류의 기능을 사용하여 이를 처리합니다.

Conga는 소프트웨어 구성 요소의 통합된 모음으로 Red Hat 클러스터 및 스토리지를 중앙 집중적으로 설정 및 관리합니다. Conga에는 다음과 같은 주요 기능이 있습니다:

Conga의 주요 구성 요소에는 luci 및 ricci로 이는 각각 설치될 수 있습니다. luci는 하나의 컴퓨터 상에서 실행되는 서버로 ricci를 통해 다중 클러스터 및 컴퓨터와 통신합니다. ricci는 각각의 컴퓨터 (클러스터 맴버 또는 독립형 컴퓨터)에서 실행되는 에이전트로 Conga에 의해 관리됩니다.

luci는 웹 브라우져로 액세스할 수 있으며 세가지 주요 기능을 제공하며 이는 다음과 같은 탭을 통해 액세스할 수 있습니다:

클러스터 또는 스토리지를 관리하기 위해, 관리자는 luci 서버에 클러스터 또는 컴퓨터를 추가 (또는 등록)해야 합니다. 클러스터 또는 컴퓨터가 luci에 등록되면 각각의 컴퓨터에 대한 FQDN 호스트명 또는 IP 주소가 luci 데이터베이스에 저장됩니다.

다른 luci 인스턴스에서 하나의 luci 인스턴스에 대한 데이터베이스를 지정할 수 있습니다. 이러한 기능은 luci 서버 인스턴스를 복사하는 방법을 제공하며 효율적인 업그레이드 및 테스팅 경로를 제공합니다. luci 인스턴스 설치 시 데이터 베이스는 비어있게 됩니다. 하지만 새로운 luci 서버를 지정할 때 기존의 luci 서버에서 모든 또는 일부분의 luci 데이터베이스를 가져올 수 있습니다.

각각의 luci 인스턴스는 초기 설치 — 관리에서 하나의 사용자를 갖습니다. 관리자는 luci 서버에 시스템을 추가할 수 있습니다. 또한 관리자는 추가 사용자 계정을 생성하고 사용자에 대해 luci 데이터 베이스에 등록된 클러스터 및 컴퓨터 액세스 권한을 결정할 수 있습니다. 새로운 luci 서버에서 클러스터와 컴퓨터를 가져올 수 있는 것처럼 배치(batch) 옵션으로 사용자를 가져올 수 있습니다.

luci 서버에 관리할 컴퓨터를 추가할 때 인증 과정은 한 번 이루어 집니다. 그 이후로는 (인증서가 CA에 의해 취소되지 않는 한) 인증 과정이 필요하지 않게 됩니다. 다음으로 luci 사용자 인터페이스를 통해 클러스터 및 스토리지를 원격으로 설정 및 관리할 수 있습니다. luci 및 ricci는 XML을 통해 서로 통신합니다.

다음에서는 세 가지의 주요한 luci 탭을 보여주고 있습니다: homebase, cluster, storage.

Conga에 관한 보다 자세한 내용은 Red Hat 클러스터 설정 및 관리를 참조하시거나 luci 서버에 있는 온라인 도움말에서 참조하시기 바랍니다.

This section provides an overview of the system-config-cluster cluster administration graphical user interface (GUI) available with Red Hat Cluster Suite. The GUI is for use with the cluster infrastructure and the high-availability service management components (refer to 1.3절. “Cluster Infrastructure” and 1.4절. “고가용성 서비스 관리 ”). The GUI consists of two major functions: the Cluster Configuration Tool and the Cluster Status Tool. The Cluster Configuration Tool provides the capability to create, edit, and propagate the cluster configuration file (/etc/cluster/cluster.conf). The Cluster Status Tool provides the capability to manage high-availability services. The following sections summarize those functions.

In addition to Conga and the system-config-cluster Cluster Administration GUI, command line tools are available for administering the cluster infrastructure and the high-availability service management components. The command line tools are used by the Cluster Administration GUI and init scripts supplied by Red Hat. 표 1.1. “명령행 도구 ” summarizes the command line tools.

CONTROL/MONITORING 패널에서는 런타임 상태를 보여줍니다. 이는 pulse 데몬, LVS 라우팅 테이블, LVS 스폰 nanny 프로세스의 상태를 보여줍니다.

The GLOBAL SETTINGS panel is where the LVS administrator defines the networking details for the primary LVS router's public and private network interfaces.

The top half of this panel sets up the primary LVS router's public and private network interfaces.

The next three fields are specifically for the NAT router's virtual network interface connected the private network with the real servers.

REDUNDANCY 패널에서는 백업 LVS 라우터 노드를 설정하고 다양한 하트비트 모니터링 옵션을 설정합니다.

나머지 패널에서는 하트비트 채널을 설정하며, 문제 발생의 경우 백업 노드가 주요 노드를 모니터하는데 사용됩니다.

VIRTUAL SERVERS 패널에서는 최근에 지정된 가상 서버에 대한 정보를 보여줍니다. 각각의 테이블 엔트리에서는 가상 서버의 상태, 서버 이름, 서버에 지정된 가상 IP, 가상 IP의 넷마스크, 서비스가 통신하는 포트 번호, 사용되는 프로토콜, 가상 장치 인터페이스의 상태를 보여 줍니다.

VIRTUAL SERVERS 패널에 있는 각각의 서버는 다음의 스크린이나 또는 하부 섹션에서 설정할 수 있습니다.

서비스를 추가하려면 ADD 버튼을 클릭합니다. 서비스를 삭제하려면 가상 서버 옆에 위치한 라디오 버튼을 클릭하여 삭제하려는 서비스를 선택한 후 DELETE 버튼을 클릭합니다.

테이블에 있는 가상 서버를 활성화 또는 비활성화하기 위해 라디오 버튼을 클릭한 후 (DE)ACTIVATE 버튼을 클릭합니다.

가상 서버를 추가한 후에 왼쪽에 있는 라디오 버튼을 클릭하여 이를 설정할 수 있으며 EDIT 버튼을 클릭하여 VIRTUAL SERVER 하부 섹션을 볼 수 있습니다.