こんにちは
記事の3番目の部分は、前の2つの付録の一種で、Proxmoxクラスターでの作業について説明しました。 このパートでは、Proxmoxでの作業で発生した問題とその解決方法について説明します。
許可されたiSCSI接続
iSCSIに接続するときにcreditsyalを指定する必要がある場合は、
Proxmoxをバイパスしてこれを行うことをお勧めします。 なんで？
- まず、 Proxmox Webインターフェースを介して許可されたiSCSI 接続を作成することができないためです。
- 第二に、承認情報を手動で指定するためにProxmoxで不正な接続を作成することを決定した場合でも、 iSCSIホストへの接続に失敗するとProxmoxはターゲット情報を上書きするため、ターゲット設定ファイルを変更するためにシステムとたむろする必要があります接続を再試行します。
手動での接続が簡単 ：
root@srv01-vmx:~
これらのコマンドは、クラスターのすべてのノードで必要なターゲットを提供するすべてのポータルに対して実行する必要があります。 または、これらのコマンドを1つのノードで実行し、残りの接続用の構成ファイルを配布できます。 ファイルは、ディレクトリ「
/ etc / iscsi / nodes 」および「
/ etc / iscsi / send_targets 」にあります。
新しいGFS2-FSノードでのマウント
GFS2ファイルシステムを新しいノードにマウントするには、もう1つのログを追加する必要があり
ます （
ファイルシステム ）。 これは次のように行われます。必要な
FSがマウントされているクラスターのノードで、コマンドが実行されます。
root@pve01:~
「
-j 」パラメーターは、
FSに追加するログの数を指定します。
このコマンドは失敗する可能性があります。
create: Disk quota exceeded
エラーの原因：
GFS2ボリューム内には実際には1つのファイルシステムではなく、2つのファイルシステムがあります。 別のファイルシステムはビジネス用です。 必要に応じて、オプション「
-o meta 」を追加してマウントできます。 この
FS内の変更は、データファイルシステムの破壊につながる可能性があります。 ログを
FSに追加すると、
メタファイルシステムはディレクトリ「
/ tmp / TEMP_RANDOM_DIR 」にマウントされ、その後ログファイルがその中に作成されます。 不明な理由により、カーネルは、オブジェクトを作成するためのマウントされたクォータがマウントされた
meta-FSを超えていると時々信じます。そのため、このエラーが発生します。
GFS2にデータを再マウントして（
このFSにあるすべての仮想マシンを停止する必要があるので）この状況から抜け出し、add logコマンドを再度実行してください。 また、ログを追加する最後の失敗した試行から
meta-FSをアンマウントする必要があります。
cat /proc/mounts | grep /tmp/ | grep -i gfs2 | awk '{print $2}' | xargs umount
コンテナ内にデータソースをマウントする
コンテナー仮想化テクノロジーは、ホストが仮想マシンと通信するためのほぼ無限の可能性があるため、優れています。
コンテナが起動すると、
vzctlは次の一連のスクリプト（
存在する場合 ）を実行しようとします。
- /etc/pve/openvz/vps.premount
- /etc/pve/openvz/CTID.premount
- /etc/pve/openvz/vps.mount
- /etc/pve/openvz/CTID.mount
- /etc/pve/openvz/CTID.start
停止すると、次のスクリプトが実行されます。
- /etc/pve/openvz/CTID.stop
- /etc/pve/openvz/CTID.umount
- /etc/pve/openvz/vps.umount
- /etc/pve/openvz/CTID.postumount
- /etc/pve/openvz/vps.postumount
ここで、「
CTID 」はコンテナ番号です。 「
vps。* 」スクリプトは、コンテナの操作中に実行されます。 スクリプト「
* .start 」および「
* .stop 」はコンテナのコンテキストで実行され、残りはすべてホストのコンテキストで実行されます。 したがって、コンテナにデータマウントを追加することで、コンテナの開始/停止プロセスをスクリプト化できます。 以下に例を示します。
コンテナ内にデータディレクトリをマウントする
コンテナが大量のデータを処理する場合、このデータをコンテナ内に保存せず、ホストからマウントしようとします。 このアプローチには、2つの肯定的な側面があります。
- コンテナは小さく、すぐにProxmoxによってバックアップされます。 コンテナの機能をすばやく復元/複製する機会がいつでもあります。
- コンテナデータは、それが提供するすべての設備（マルチレベルバックアップ、ローテーション、統計など）を備えた成人用バックアップシステムによって集中的にバックアップできます。
ファイル「
CTID.mount 」の内容：
コンテナ内にファイルシステムをマウントする
ホストには、コンテナに指定する必要があるものがあります。 ファイル「
CTID.mount 」の内容：
コンテナ内のファイルにファイルシステムをマウントする
なぜこれが必要なのですか？ トリッキーな製品（
たとえば、 Splunk ）が
simfsを使用したくない
場合 、または特定の条件下で
GFS2の速度に満足できない場合。 たとえば、小さなファイルのヒープに何らかのキャッシュがあります。
GFS2は、大量の小さなファイルでは非常に速く動作しません。 次に、
GFS2 （
ext3 ）とは異なるファイルシステムをホスト上に作成し、コンテナーに接続できます。
ループデバイスをファイルからコンテナにマウントし
ます 。
まず、ファイルを作成します。
root@srv01:/storage
ファイル内の
FSをフォーマットします。
root@srv01:/storage
ファイル「
CTID.mount 」の内容：
停止時にコンテナ内の外部データをアンマウントする
コンテナが停止すると、システムはそれに接続されているすべてのファイルシステムを自動的にアンマウントしようとします。 しかし、特にエキゾチックな構成では、彼女はこれを行うことができません。 したがって、
念のため、単純なスクリプト「
CTID.umount 」の例を次に示します。
クラスター化されていないファイルシステムを使用するクラスターで作業する
何らかの理由でクラスター
FSを使用する必要がない場合（
作業の安定性に適さない、パフォーマンスに適さないなど ）、単一のリポジトリーで作業する場合、このオプションは可能です。 これには次のものが必要です。
- クラスタノードごとにCLVMの個別の論理ボリューム
- 通常のコンテナ操作用のプライマリストレージ
- 障害/シャットダウンの場合に外部ノードボリュームを緊急にマウントするための空のバックアップストレージ
手続き
各クラスターノードには、
CLVMで独自の論理ボリュームがあり、フォーマットします。
主記憶域を作成します。 クラスターのすべてのノードに同じ名前のディレクトリを作成します（
たとえば、「/ storage」 ）。 論理ボリュームをその中にマウントします。
Proxmox管理
パネルで、タイプ「
Directory 」のストレージを
作成し 、「
STORAGE 」などの名前を付けて、共有されていないことを伝えます。
バックアップストレージを作成します。 クラスターのすべてのノードに同じ名前のディレクトリを作成します（
例： "/ storage2" ）。
Proxmox管理
パネルで、「
Directory 」タイプのリポジトリを
作成し 、「
STORAGE2 」などの名前を付けて、共有されていないことを伝えます。 ノードの1つが落下/シャットダウンした場合、そのボリュームをクラスターのそのノードの「
/ storage2 」
ディレクトリにマウントします。
結果として私たちには何がありますか：
- ノード間のコンテナーの移行（ オンラインを含む ）（ 側面からコンテナーにデータがマウントされていない場合 ）。 コンテナはそれぞれコピーによってノードからノードに転送され、移行時間はコンテナ内のデータ量に依存します。 データが多いほど、ノード間でコンテナが転送される時間が長くなります。 同時に増加するディスク負荷を忘れないでください。
- （ アンダー ）フォールトトレランス。 ノードが落ちた場合、そのデータは隣接ノードにマウントでき、理論的には、それらの操作を開始できます。
なぜ「
下 」で、なぜ「
理論的に 」：
仮想マシンは、「
/ storage 」ディレクトリにある「
STORAGE 」リポジトリに存在します。 デッドノードからのディスクは、「
/ storage2 」
ディレクトリにマウントされ、
Proxmoxはコンテナを参照しますが、そこからコンテナを起動することはできません。 このストレージにある仮想マシンを上げるには、次の3つのアクションを実行する必要があります。
- 火災の被害者に、彼らの新しい家が「 / storage 」ディレクトリではなく、 / storage2ディレクトリであることを知らせるため。 これを行うには、ディレクトリ「 / etc / pve / nodes / dead_name / openvz 」の各ファイル「 * .conf 」で、 VE_PRIVATE変数の内容を「 / storage / private / CTID 」から「 / storage2 // private / CTID 」に変更します。
- その無生物ノードからの仮想コンピューターが、現在この稼働中のノードに配置されていることをクラスターに伝えます。 これを行うには、すべてのファイルをディレクトリ「 / etc / pve / nodes / dead_name / openvz 」からディレクトリ「 / etc / pve / nodes / live_node / openvz 」に転送するだけです。 おそらくこれには何らかの正しいAPI命令がありますが、私たちはこれを気にしませんでした:)
- 焦げたコンテナごとにクォータをリセットします（念のため）。
vzquota drop CTID
それだけです コンテナを実行できます。
デッドノードからのコンテナがスペースをほとんど占有しない場合、または非常に高速なディスクがある場合、または待つ余裕がある場合、必要なコンテナを「
/ storage2 / private 」から「
/ storage / private 」
クラスターがバラバラになった場合
クラスターは不機嫌な生き物であり、ポーズになることもあります。 たとえば、ネットワークの大規模な問題の後、または大規模な停電によるものです。 ポーズは次のようになります。クラスターストレージにアクセスすると、現在のセッションがブロックされ、フェンスドメインのステータスをポーリングすると、「
待機状態メッセージ 」という形式のアラームメッセージが表示され、接続エラーが
dmesgに注がれます。
クラスターを復活させようとしても成功しない場合、最も簡単なことは、クラスターのすべてのノードの
フェンスドメインへの自動エントリを無効にし（
ファイル "/ etc / default / redhat-cluster-pve" ）、すべてのノードを順番に再起動することです。 ノードが単独で再起動できないという事実に備えなければなりません。 すべてのノードが再起動したら、
フェンスドメインに手動で接続し、
CLVMを起動します。 以前の記事では、これを行う方法を書いています。
おそらくそれだけです。
次のパートでは、クラスター内の作業を自動化する方法について説明します。
ご清聴ありがとうございました！