アクティブ/パッシブモードで2ノードクラスター(-like?)ソリューションを構築する必要があります。つまり、一方のサーバーがアクティブであり、もう一方のサーバーはパッシブ(スタンバイ)であり、データをアクティブから継続的にレプリケートします。 KVMベースの仮想マシンはアクティブノードで実行されます。
何らかの理由でアクティブノードが使用できない場合は、手動で手動で2番目のノードに切り替えます(アクティブになり、他のパッシブになります)。
私はこのチュートリアルを見ました: https://www.alteeve.com/w/AN!Cluster_Tutorial_2#Technologies_We_Will_Use
ただし、私は完全自動フェイルオーバーを信頼して複雑なものを構築し、正しく動作することを信頼するには十分な勇気はありません。スプリットブレインの状況、複雑さの失敗、データ破損などのリスクが高すぎますが、最大のダウンタイム要件は、即時の自動フェイルオーバーを必要とするほど深刻ではありません。
この種の構成を構築する方法に関する情報を見つけるのに苦労しています。これを実行した場合は、回答でHOWTO情報を共有してください。
あるいは、Linuxノードで信頼性の高い自動フェイルオーバーを構築することは可能ですか? Linuxの高可用性に関する問題は、8年前のようにこの概念への関心が高まっているようで、多くのチュートリアルが今ではかなり古いということです。これは、実際にはHAに実質的な問題があった可能性があり、一部または多くのシステム管理者がHAを単に削除したことを示唆しています。
それが可能である場合は、それを構築する方法と、運用環境でを実行しているクラスターでの経験を共有してください。
私はあなたが説明した設定で非常に類似したインストールをしています:a KVM DRBDアクティブ/パッシブを介したstanbyレプリカを持つサーバー。システムを可能な限りシンプルにする(そして自動分割を避けるためにつまり、顧客がクラスターネットワークを操作しているため)、クラスターの自動フェールオーバーも取りやめました。
このシステムは5年以上前のもので、問題はありませんでした。私のボリューム設定は次のとおりです:
フェイルオーバーが発生した場合に役立つシェルスクリプトをいくつか作成しました。あなたはそれらを見つけることができます ここ
システムは、高速スナップショットやファイルベース(ボリュームベースではなく)の仮想ディスクなどの機能を犠牲にしても、最大のパフォーマンスが得られるように設計されていることに注意してください。
似たようなアクティブ/パッシブセットアップを今すぐ再構築すると、send/recv
を介したZFSと継続的な非同期レプリケーションの使用に大きく依存します。これは、リアルタイムのブロックベースのレプリケーションではありませんが、90%以上の場合には十分です。
リアルタイムレプリケーションが本当に必要な場合は、ZVOL + XFSの上でDRBDを使用します。実際のところ、このようなセットアップと自動ペースメーカースイッチを私のラボでテストしました。 (ZoLのように)3rdyパーツモジュールを使用できない場合は、lvmthin
ボリューム+ XFSの上にDRBDリソースを使用します。
何千人ものユーザーがチェックして信頼性を証明したものを使ってみませんか? StarWind VSAN Freeなどの無料のHyper-Vサーバーを導入するだけで、問題なく真のHAを取得できます。このマニュアルをご覧ください: https://www.starwindsoftware.com/resource-library/starwind-virtual-san-hyperconverged-2-node-scenario-with-hyper-v-server-2016
DRBDを完全にセットアップして、完全に手動で使用できます。プロセスはまったく複雑であってはなりません。あなたは単にPacemakerまたはRgmanagerクラスタがすることを、手動で行います。基本的に:
当然、これには両方のノードに適切なパッケージがインストールされており、VMの構成と定義が両方のノードに存在している必要があります。
Linux HAスタック(コロシンクとペースメーカー)が引き続き積極的に開発およびサポートされていることを確認できます。多くのガイドは古く、ソフトウェアは10年前から存在しています。適切に行われた場合、大きな問題はありません。放棄されたわけではありませんが、もはや「新しくて刺激的な」ものではありません。
アクティブ/パッシブクラスターは依然として多くの場所でひどく使用されており、運用環境で実行されています。以下のproduction設定を見つけてください。問題なく機能しており、手動モード(orchestrate=start
)、または自動フェイルオーバーを有効にします(orchestrate=ha
)。 zfs send/receiveとzfsスナップショットの恩恵を受けるためにzfsを使用しますが、同期レプリケーションを希望する場合はdrbdを使用することもできます。
前提条件:
手順:
root @ node1:〜$ svcmgr -s win1 print config
[DEFAULT]
env = PRD
nodes = node1.acme.com node2.acme.com
id = 7a10881d-e5d5-4817-a8fe-e7a2004c5520
orchestrate = start
[fs#1]
mnt_opt = rw,xattr,acl
mnt = /srv/{svcname}
dev = data/{svcname}
type = zfs
[container#0]
type = kvm
name = {svcname}
guestos = windows
shared = true
[sync#1]
src = data/{svcname}
dst = data/{svcname}
type = zfs
target = nodes
recursive = true
schedule = @12h
いくつかの説明:
{svcname}
サービス設定ファイルの実際のサービス名(win1)を指す参照data/win1
マウントポイント/srv/win1
win1
sync#1
は、スレーブノードへの非同期zfsデータセットレプリケーションを宣言するために使用されます(node1のdata/win1はnode2のdata/win1に送信されます)。この例では12時間に1回(zfs send/receiveはopensvcエージェントによって管理されています)いくつかの管理コマンド:
svcmgr -s win1 start
サービスを開始svcmgr -s win1 stop
サービスを停止しますsvcmgr -s win1 stop --rid container#0
設定ファイルでcontainer#0が参照するコンテナを停止しますsvcmgr -s win1 switch
サービスを他のノードに再配置しますsvcmgr -s win1 sync update
増分zfsデータセットコピーをトリガーしますsvcmgr -s win1 sync full
zfsデータセット全体のコピーをトリガーします私が管理している一部のサービスでは、定期的に(毎日/毎週/毎月)zfsスナップショットも必要です。この場合、次の構成スニペットをサービス構成ファイルに追加すると、opensvcエージェントがその仕事をします。
[sync#1sd]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61
keep = 7
name = daily
recursive = true
sync_max_delay = 1d
[sync#1sw]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61 Sun
keep = 4
name = weekly
recursive = true
sync_max_delay = 7d
[sync#1sm]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61 * *:first
keep = 6
name = monthly
recursive = true
sync_max_delay = 31d
要求に応じて、lvm/drbd/kvm configも1つ追加します。
drbdリソース構成/etc/drbd.d/kvmdrbd.res
:
resource kvmdrbd {
device /dev/drbd10;
disk /dev/drbdvg/drbdlv;
on node1 {
address 1.2.3.4:12345;
meta-disk internal;
}
on node2 {
address 4.3.2.1:12345;
meta-disk internal;
}
}
opensvcサービス設定ファイル/etc/opensvc/kvmdrbd.conf
:
root@node1# svcmgr -s kvmdrbd print config
[DEFAULT]
env = PRD
nodes = node1.acme.com node2.acme.com
id = 7a10881d-f4d3-1234-a2cd-e7a2018c4321
orchestrate = start
[disk#1]
type = lvm
vgname = {env.drbdvgname}
standby = true
[disk#2]
type = drbd
standby = true
shared = true
res = {svcname}
[fs#0]
mnt = {env.basedir}/{svcname}
type = ext4
dev = /dev/{env.drbddev}
shared = true
[container#0]
type = kvm
name = {svcname}
shared = true
[sync#i0]
schedule = @1440
[env]
basedir = /srv
drbddev = drbd10
drbdvgname = drbdvg
いくつかの説明:
disk#1
:大きな論理ボリュームをホストするlvm vgです。 5GB以上である必要があります。disk#2
:drbdリソース名が指すdrbdディスクです。 opensvcサービスの名前が「foo」の場合、/ etc/drbd.d/foo.resが必要です。または、サービス設定ファイルのdisk#2.resパラメータを変更します。fs#0
:kvmゲストのすべてのディスクファイルをホストするメインファイルシステムcontainer#0
:kvmゲスト、例のopensvcサービスと同じ名前。エージェントは、サービスの開始を受け入れる前にpingチェックを実行するために、kvmゲストをDNS解決できる必要があります(ping回答の場合、kvmゲストはすでにどこかで実行されているため、開始することはお勧めしません。ダブルスタート保護が保証されていますopensvcエージェントによる)standby = true
:サービスが他のノードで実行されているとき、このリソースは稼働し続けなければならないことを意味します。この例では、drbdを正常に実行し続ける必要がありますshared = true
: https://docs.opensvc.com/latest/agent.service.provisioning.html#shared-resources私は現在、非常に類似したシステムを使用しています。 2台のサーバー、1台がアクティブ、1台がバックアップで、どちらも内部でいくつかのVMを実行しています。データベースが複製されており、ファイルサーバーはrsyncと常に同期しています(ただし、一方向のみ)。緊急の場合は、セカンダリサーバーがサービスを提供しています。 PacemakerとCorosyncを使用するという考えがありましたが、これは100%でなければならないため、実験する勇気がありませんでした。私の考えは、サーバーを監視するNginXです。これは私がWebアプリケーションを使用しているので可能ですが、あなたの場合、それを使用できるかどうかわかりません。 DRBDは私にとって混乱です。以前のサーバーがそれを使っていたので、動いているように見えましたが、私は人体を解剖しようとしているように感じました。
これをチェックしてください、それはあなたを助けるかもしれません: http://jensd.be/156/linux/building-a-high-available-failover-cluster-with-pacemaker-corosync-pcs
実際、私がすでに試してみた小さな環境では、難しく見えません。習得、作成、保守が簡単です。実はこれがあなたが探しているものだと思います。