特集: DRBD9紹介 第2回「自動プロモーション機能」
連載の第2回目では、HAクラスタシステムの設定と運用を大幅に簡素化できる「自動プロモーション」機能を紹介します。
プライマリとセカンダリ
DRBDには、「プライマリ」と「セカンダリ」という2種類のロール(役割)があります。
左側のサーバでプライマリ・ロールのDRBDが動作し、アプリケーションからの書き込みデータを受け取っています。プライマリDRBDはデータをローカルディスクに書き込むと同時に、セカンダリDRBDに同じデータを送ります(黄色の太い矢印)。
セカンダリDRBD (右側のサーバ)は、プライマリDRBDから受け取ったデータをローカルディスクに書き込みます。セカンダリDRBDはプライマリDRBD以外からの読み書きリクエストをすべて拒否します。
プライマリDRBDのみが両方のサーバのDRBDレプリケーション領域ブロックストレージにデータを書き込めるため、ストレージ上のデータの首尾一貫性を維持できます。
プライマリとセカンダリの切り替え
DRBDを使ってデータを冗長化すれば、2台のサーバのどちらがダウンしても、生き残ったサーバに書き込まれていたデータを使ってサービスを継続できます。しかしこのような切り替えを実現するには、プライマリとセカンダリの切り替えが必要になります。
- セカンダリ・ロールからプライマリ・ロールに切り替える(昇格、プロモーション)
- DRBD管理領域をマウントする
- データを読み書きする
DRBD管理領域の利用が終ったときも、次のような手順が必要です。
- DRBD管理領域をアンマウントする
- DRBDをセカンダリ・ロールに切り替える(降格、デモーション)
DRBD 8までは、drbdadm primaryあるいはdrbdadm secondaryというロール切り替えコマンドを管理者が実行しない限り、ロールを切り替えることはできませんでした。
ロール切り替えの自動化
DRBD 9は多ノードレプリケーションをサポートするだけでなく、同時に複数セットのDRBD管理領域が日常的に使われることを想定しています。自動プロモーション機能は、多ノード、多数のデータ領域の管理を効率化するためにDRBD 9.0で導入された機能です。
DRBD管理領域を読み書きしたいマシンでは、事前の儀式なしにDRBD管理領域をマウントすればよく、またアンマウントすれば自動的にDRBDはセカンダリ・ロールに降格します。
HAクラスタ設定の簡素化
DRBDは、PacemakerやCorosyncと組み合わせた高可用クラスタのストレージ基盤として広く使われています。自動プロモーション機能を活用すれば、クラスタ設定を大幅に簡素化できます。
DRBD 8ベースのクラスタ設定の例
DRBD 8までは、DRBDの制御は複雑で、したがってクラスタ設定も複雑なものになっていました。
primitive res_drbd_r0 ocf:linbit:drbd . . . . ms ms_drbd_r0 res_drbd_r0 . . . . primitive res_vip IPaddr2 . . . . primitive res_mount Filesystem . . . . primitive res_service service_RA . . . . group group_services res_vip res_mount res_service . . . . order order_drbd_service . . . . colocation colocation_drbd_service . . . .
高可用クラスタが提供するサービスがDRBD管理領域へのアクセスを必要とする場合には、アクティブサーバ側でサービスを起動する前にDRBDをプライマリ・ロールに昇格させておく必要があり、個々の手続きと順序関係をすべて細かく指定する必要があったわけです。
自動プロモーション機能を使ったクラスタ設定の例
自動プロモーション機能を使うと、上と同じ構成のクラスタの設定は、次のように簡素化できます。
primitive res_vip IPaddr2 . . . . primitive res_mount Filesystem . . . . primitive res_service service_RA . . . . group group_services res_vip res_mount res_service
DRBD 8ベースの運用とは異なり、DRBD自体はサーバ起動時に自動起動しておくことになります。
そして、アクティブになるサーバ側では、単にファイルシステムをマウントするだけで、サービスを起動できるようになります。