サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
blog.drbd.jp
DRBD9のDocker Volumeプラグイン docker docsを見ると確認できるのですが、DRBD9はdockerのボリュームプラグインを提供しています。 Dockerはソフトウェアコンテナ内のアプリケーションのデプロイメントを自動化するオープンソースソフトウェアです。(docker自体の詳細な説明は割愛いたします) dockerはストレージ利用については課題がありました。コンテナを停止すると、基本的にはデータがすべて消えてしまう点です。 一応dockerではホスト上のディレクトリをコンテナのストレージに使用することで永続的なストレージとする事が可能です。しかしこれではコンテナをこのホストとは別のホストで起動する際にはデータにアクセスができないなどデータ共有においては問題となります。また実運用するのであれば可用性を上げるためデータ冗長化もしておきたいでしょう。 そこで、Doker
図の一覧 1.1. LinuxのI/OスタックでのDRBDの位置2.1. 同期時間2.2. DRBDリソーススタッキング2.3. DRBDデータ再配置4.1. N 個のホストの時のコネクション数4.2. syncer 速度の例(有効帯域幅が110MB/sの場合)4.3. syncer 速度の例(有効帯域幅が80MB/sの場合)4.4. 単一スタックの構成4.5. DRBDデータ再配置7.1. PacemakerクラスタのDRBDリソースのスタック7.2. PacemakerクラスタのDRBDリソースのスタック7.3. SANベースのクラスタ間のレプリケートにDRBDを用いる9.1. LVM概要16.1. DRBDメタデータサイズの計算(正確)16.2. DRBDメタデータサイズの見積り(概算)16.3. 新規データ世代の開始時に変化するGIタプル16.4. 同期速度とターゲットの同期時間に
LVM論理ボリュームをDRBDの下位デバイスとして使用する。 DRBDデバイスをLVMの論理ボリュームとして使用する。 上記の2つを組み合わせ、DRBDを使用して階層構造のLVMを実装する。 上述の用語についてよく知らない場合は、「LVMの基礎」を参照してくださいまた、ここで説明する内容にとどまらず、LVMについてさらに詳しく理解することをお勧めします。 LVM2は、Linuxデバイスマッパフレームワークのコンテキストにおける論理ボリューム管理の実装です。元のLVM実装とは名前と略語を除き、実際には何の共通点もありません。古い実装(現在ではLVM1と呼ばれる)は時代遅れとみなされているため、ここでは取り上げません。 LVMを使用する際には、次に示す基本的なコンセプトを理解することが重要です。 物理ボリューム(PV). PV (Physical Volume: 物理ボリューム)はLVMによっ
図の一覧 1.1. LinuxのI/OスタックでのDRBDの位置2.1. 同期時間2.2. DRBDリソースの積み重ね5.1. syncer 速度の例(有効帯域幅が110MB/sの場合)5.2. cyncer 速度の例(有効帯域幅が80MB/sの場合)7.1. PacemakerクラスタのDRBDリソースのスタック7.2. PacemakerクラスタのDRBDリソースのスタック7.3. SANベースのクラスタ間のレプリケートにDRBDを用いる9.1. LVM overview16.1. DRBDメタデータサイズの計算(正確)16.2. DRBDメタデータサイズの見積り(概算)16.3. 新規データ世代の開始時に変化するGIタプル16.4. 再同期開始時のGIタプルの変化16.5. 再同期完了時のGIタプルの変化16.6. 同期速度とターゲットの同期時間にもとづくアクティブエクステントの計算
COROSYNC_CONFSection: Corosync Cluster Engine Programmer’s Manual (5) Updated: 2012-10-10 名前corosync.conf – corosync実行形式の設定ファイル 書式/etc/corosync/corosync.conf 説明corosync.confはcorosync実行部を制御するのに必要な種々のパラメータを規定します。空白行や#で始まる行は無視されます。設定ファイルは括弧で囲まれたトップレベルディレクティブから構成されています。有効なものは以下です。 totem {}totemプロトコルの設定オプションを記載するトップレベルのディレクティブです。logging {}ログの設定オプションを記載するトップレベルのディレクティブです。quorum {}クォーラムの設定オプションを記載するトップレベ
Pacemakerで管理しているLinux-HAクラスタのメンテナンス時に、「一部のサービスを停止させるが、フェールオーバが発生しないようにしたい」、などの場合もあるかと思います。そんな時に使える機能が、メンテナンスモードです。 メンテナンスモードとはメンテナンスモードを有効にすると、Pacemakerは動作したままですが、リソースの起動/停止/監視をいっさい行わなくなります。 例えばクラスタリソースとして動作しているデータベースをメンテナンスするために一時停止しても、メンテナンスモードの最中であれば、フェールオーバは起こりません。メンテナンスが終わってデータベースを再起動してから、メンテナンスモードを無効に戻せばいい、ということになります。 使用方法メンテナンスモードを有効にします。# crm configure property maintenance-mode=true必要なメンテナ
DRBD9の風変わりな新機能は「DRBDクライアント」です。これは、データを読み書きするローカルストレージを割り当てていないDRBDインスタンスのことで、ディスクレスDRBDと呼んでもいいでしょう。2ノードレプリケーションに限定されているDRBD8では、ディスクレスDRBDに有用性はなく、逆に故障修理の対象になります。しかしDRBD9では、3ノード以上のレプリケーションの1台でDRBDクライアントを積極的に活用し、まったく新しいストレージソリューションを実現できます。 DRBDクライアントの概要下図では、上段の3台のサーバはそれぞれ何らかのアプリケーションを実行するサーバ、下段の5台のサーバはDRBD9で多重にレプリケートしているストレージクラスタです。それぞれ4ノードでレプリケートする3つのDRBDリソースA、B、およびCが動作しています。ただし、アプリケーション実行サーバ群のDRBDは
このページを最初にブックマークしてみませんか?
『DRBD Tech Info』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く