はじめに
今回は、LifeKeeperの設計時に考えなければいけない内容についてアウトプットしていきたいと思います。
僕自身、半年の間にLifeKeeperの設計～構築手順書の落とし込みまで経験しました。
その中での経験を踏まえながら紹介していきたいと思います。
LifeKeeperとは？
LifeKeeperとは、SIOSが出している「HAクラスター」のミドルウェア製品になります。
特徴
- GUIベースで構築することができる。
- リソースの起動順序をGUI画面で設定することができる。
- 「共有ディスク構成」のみならず「データレプリケーション構成」も可能
詳細については、公式サイトをご確認下さい。
https://sios.jp/products/lkdk/product/lifekeeper.html
※HAクラスターの仕組みについては僕のブログにて紹介しています。
https://satton-infra.com/cluster/
こちらの記事の前提
- 社内でLifeKeeperを需要がある分構築する環境
- HAクラスター構成
- アプリケーション側のライセンスは考えない。
僕が関わったLifeKeeperの構成
※クラスター上に乗せるアプリケーションについては関わっていません。
関わった領域としては、アプリケーションより下のレイヤーになります。
仮想サーバー
- HyperVisor
vSphere6.7(ESXi6.7)
- VM(「サーバー」の部分)
RHEL(6.7/6.9/7.3/7.6)
CentOS(6.7/6.9/7.3/7.6)
- NIC
Service用NIC × 1
コミュニケーションパス用NIC × 2
- 共有ディスク/Quorumディスク
VMDK/iSCSI
物理サーバー
- 物理サーバー
RHEL(6.7/6.9/7.3/7.6)
CentOS(6.7/6.9/7.3/7.6)
- NIC
Service用NIC × 1
コミュニケーションパス用NIC × 2
- 共有ディスク/Quorumディスク#1,#2
iSCSI
※コミュニケーションパス用NICにて接続
考えるべき内容とは？
考えるべき内容についてはこちらになります。
※全ては網羅できていません。参考程度に御覧頂ければと思います。
- ライセンス管理
- ストレージ
- コミュニケーションパス用のセグメント
- GUI画面の表示方法
- 起動順序(依存関係)
では記事にて掘り下げていきます。
ライセンス管理
ライセンスを管理する方法についてしっかり検討する必要があります。
今回上げた構成の場合の必要なライセンスはこちらになります。
仮想サーバー
基本ライセンス(仮想用) × 2
Quorum用ライセンス × 2
(iSCSI用ライセンス ×2)
備考)
・iSCSI用ライセンスはiSCSI接続の場合のみ必要
・ストレージがVMDKの場合は、追加で必要なライセンスはなし
・基本ライセンス/iSCSI用ライセンスはサーバ台数分、Quorum用ライセンスは使いまわしが可能物理サーバー
基本ライセンス(物理用) × 2
Quorum用ライセンス × 2
iSCSI用ライセンス ×2
備考)
・iSCSI用ライセンスはiSCSI接続の場合のみ必要
・基本ライセンス/iSCSI用ライセンスはサーバ台数分、Quorum用ライセンスは使いまわしが可能
特筆とする点はこちらになります。
- 基本ライセンスが仮想サーバーと物理サーバーで相違がある。
- iSCSI接続には別途iSCSI用ライセンスが必要
このように複数の種類のライセンスがあります。
そのため、ライセンス管理をするための仕組みを考える必要があります。
例えば、このような形になります。
- 1クラスターで何のライセンスを使用するのか？
- ライセンスの残数はどれくらいか？
- 誰がライセンスを使用したのか？
私はこの辺りのライセンス管理表を作成後に展開しました。
このように構築作業をする際に「あれ？ライセンスがない！」という状況を避けるための取組みをする必要があります。
ストレージ
ストレージについても考慮する必要があります。
理由としては、ルールが統一されていない場合に管理がしづらいからです。
具体例としては、こちらになります。
VMDKの場合
・どこのデータストアにVMDKボリュームを作成するのか？
・データストア内のディレクトリ構成はどうするか？
・VMDKのファイル名をどのように管理するか？
・データストアの空き容量はどれくらいか？
iSCSIの場合
・どのストレージからボリュームを切り出すか？
・切り出したボリュームの名前はどうする？
(ストレージの種類による)
・SAN(Storage Area Network)の環境があるか？ネットワーク面をどうするか？
このようにボリュームを切り出すストレージのルールについても考える必要があります。
コミュニケーションパス用のセグメント
コミュニケーションパスとは、主系と副系で冗長化するために必要な経路のことです。
LifeKeeperでは、こちらのコミュニケーションパスを2本で構成します。
要件としては、両系同士が通信できていれば問題ないです。
(閉じられたネットワークでも問題ない)
コミュニケーションパスのセグメントを考えるポイント
・SAN(Storage Area Network)と同様のセグメントにするのか？
※ストレージ要件が「iSCSI」の場合
・別でセグメントを立て、そこに接続するのか？
・セグメント/IPアドレスの管理はどうするのか？
このようにコミュニケーションパスのセグメントをどうするか考える必要があります。
GUI画面の接続方法
LifeKeeper管理画面の接続方法には2通りあります。
- Linuxサーバーのデスクトップ(GNOME/KDE)にてGUI画面表示
- 端末(Windows)にてhttp接続でGUI画面表示
「端末からの接続の方が楽じゃん！」
このように最初は思いました。
しかし、結果的にLinuxサーバーにてGUI画面に接続する方法になりました。
理由
・端末に「Java」を導入する必要がある。
・端末のhostsの設定を変更する必要がある。
現場のルール上、理由として挙げている変更をすることができませんでした。
消去法としてLinuxサーバーからのGUI画面接続方法になりました。
それぞれの特徴について上げていきたいと思います。
Linuxサーバーにデスクトップ環境(GNOME/KDE)をインストールする方法
・別に端末を用意する必要がない(サーバー自体にデスクトップ環境をインストールするため)
・デスクトップ環境インストール時のパッケージ依存関係処理が大変
・デスクトップ環境のパッケージ分のリソースを消費してしまう
・デスクトップ環境分のCPU/メモリを消費してしまう端末からhttp接続でWEBGUIにアクセスする方法
・サーバーにデスクトップ環境を用意する必要がない
・端末からhttp接続でGUI画面を表示することができる
・端末にJavaをインストールする必要がある
・端末のhostsの変更を修正する必要がある
このように接続方法それぞれにメリット/デメリットがあります。
現場のルールに合わせてGUI画面接続方法について考える必要があります。
依存関係(起動順序)
依存関係は、簡単に言うとリソースの起動順序です。
依存関係についてもルールを定める必要があると思います。
理由は、パターンが多様だからです。
「対応できる構成」「対応できない構成」をしっかり定めておくことが大事です。
具体例
僕が対応していたLifeKeeperの基本構成はこちらになります。
補足)
起動順序:VIP→ディスク→APP
停止順序:APP→ディスク→VIP
しかし、「2つのアプリケーションをそれぞれ分けて切り替えられるようにしたい」という依頼が来ました。
その時の構成はこちらになります。
実績がなく初でしたので、検証を重ね要望通り完成させました。
他にも数えきれないくらいの複数パターンがあります。
そのため、対応できるパターンを絞っておくことが大事です。
最後に
ざっくばらんにLifeKeeperの設計や検証をする際に考えるべき内容についてまとめました。
感想としては、考えることだらけでなかなか苦労しました。
LifeKeeperの設計や検証をこれから実施する人に対して一つでも参考になればと思います。
ここまで読んで頂き有難うございました。
今回は、以上です。
Twitterのフォローを頂けると嬉しいです。
(主にインフラエンジニアのキャリアハック等について呟いています!)
https://twitter.com/satton6987