2014年10月5日日曜日

SoftLayerに冗長化NFSサーバを(その11)

NFS でエクスポートしていて領域が足りなくなってきた場合の、スケールアップの方法を書きます。

何らかの方法でディスクを追加します。
物理サーバであれば、物理 HDD を追加し、RAID コントローラで論理ディスクを作成します。
仮想サーバであれば、ポータブルストレージを追加します。
追加できないのであれば、iSCSI の LUN を追加するという手もあります。
この手順が無停止で可能であれば、サービス完全無停止で領域の拡張が可能です。無停止の要件が絶対であれば、iSCSI の LUN を追加することになります。
SoftLayer では、月額課金のポータブルストレージを購入して既存の仮想サーバにディスクを追加できますが、仮想サーバにアタッチ、デタッチする際、仮想サーバを強制的に再起動されるので注意が必要です。この点は AWS に軍配があがります。追加ボリュームのアタッチ、デタッチで OS の再起動は要求されません。もっとも、ローカルディスクの性能があまりにもしょぼいので、...。
NFS サーバのスイッチオーバ (手動フェイルオーバ) は短時間で完了するので、クライアントへの影響が比較的小さく、完全無停止にこだわらず、2回のスイッチオーバは許容する、という運用が許されるのであれば、管理者にはうれしい限りです。24x365 完全無停止は理想ですが、こだわればこだわるほど、コストに跳ね返ってきます。どうしても無理、という場合も当然あります。

同容量の /dev/sdd が Active 機、Stand-by 機の両方で追加された、という前提で手順を進めます。

以下のコマンドで、追加された HDD にパーティションを作り、LVM ボリュームグループに追加後、LVM 論理ボリュームを拡大します。Active 機と Stand-by 機の両方で実行します。
この例では、10GB 分拡大しています。


sudo parted /dev/sdd mklabel gpt

sudo parted /dev/sdd mkpart primary 1MiB 100% set 1 lvm on

sudo pvcreate /dev/sdd1

sudo vgdisplay
sudo vgextend /dev/vg0/drbd0 /dev/sdd1
sudo vgdisplay

sudo lvdisplay
sudo lvextend -L +10G /dev/vg0/drbd0
sudo lvdisplay


次に、Stand-by 機にてスナップショットを作成します。
この次の作業で、DRBD の全領域について再同期処理が走り、もしその間に Active 機が壊れると、Stand-by 機にあった同期開始前のデータも一貫性がない壊れた状態になっている可能性があり、最悪の場合、全データロストの可能性があります。同期開始前のデータを守るために、スナップショットを作成しておきます。
再同期処理中も、DRBD デバイスに対する書き込みは、Active 機への書き込み順で Stand-by 機に同期されており、一貫性が保たれているはずですが、追加領域だけでなく全領域を再同期していることからすると、チューニングができていないだけかもしれませんが、何か問題がある可能性を否定できません。
スナップショット用の領域として、拡張後のサイズと同じだけの空き容量が vg0 ボリュームグループに存在する必要があります。現実問題として、容量を確保できない状況がほとんどだと思われます。スナップショット用のサイズが確保できない場合は、スナップショットを作成後、適当な場所にスナップショットをマウントし、他のサーバ等へバックアップを取得しておきます。バックアップの取得ができたら、次の作業前にスナップショットを削除しておきます。他のサーバ等を確保できない場合や他のサーバへの転送時間が確保できない場合は、全データロストのリスクを受け入れる必要があります。障害は起こってほしくない時に限って起こるものなので、受け入れていいリスクかどうか慎重に検討する必要があります。DRBD のサポート (Linbit 社) に問い合わせても、データロストしないことの保証はしてくれないはずです。
バックアップサーバのバックアップは常に必要、と考えられるので、そのうちこの話題にも言及します。バックアップサーバのバックアップがあれば、ここでスナップショットを作成する必要はありません。


sudo lvcreate --snapshot --extents 100%FREE --name drbd0_snap /dev/vg0/drbd0


Active 機にて、DRBD 領域の拡張を行います。全領域の同期処理が走りますので、気長に完了をお待ちください。「ds:UpToDate/UpToDate」 となれば同期完了です。


sudo drbdadm resize r0
watch cat /proc/drbd


同期が完了したら、先ほど Stand-by 機で作成したスナップショットを削除します。


sudo lvremove -f /dev/vg0/drbd0_snap


最後に、Active 機にて、ファイルシステムを拡大します。全領域の同期処理が完了するのを待たなくても実行可能ですが、リスクを考えるとやめた方がよいです。


df -h /export/
sudo resize2fs /dev/drbd0
df -h /export/



(その2)にて、swap 用 HDD の監視を行っていないので HDD 追加作業の際に対応する、と予告してありましたが、ローカルディスクの監視をクラスタソフト (Pacemaker) で行うことにどれだけ意味があるのかなかなか結論が出せずにおります。
物理サーバであれば RAID コントローラを監視すべきで論理ディスクを監視すべきなのか、テストとして定期的に一部の領域を読み込んだり書き込んだりすることにどれだけ意味があるのか、よく分かりません。仮想サーバの場合も SoftLayer 側に任せておけばよいような気がしています。
意味がなくても監視設定は入れておく、でもよいとは思っています。
ただし、全 HDD に小さいパーティションを追加して (他の領域を縮小する必要もある) OS からファイルを書き込めるようにフォーマットしてマウントしておく必要があります。結構な工数がかかります。要は面倒くさい、ということです。もう一つ理由があって、ディスク監視部分は、Pacemaker 純正品ではない点 (Linux-HA Japan 謹製) も躊躇しているところです。現時点で CentOS7 用が提供されておらず、見極めが必要と考えております。
もう少し考えさせてください。

0 件のコメント:

コメントを投稿