Hebikuzure's Tech Memo

2019年8月25日

2019年8月10日

ファイル サーバーの冗長化

Filed under: Windows Tips — タグ: , , , , — hebikuzure @ 4:52 PM

今回も仕事で調べた話の記録です。

ファイルサーバーの冗長化

LAN を利用する目的の一つにファイルやフォルダーの共有があります。多くの会社では専用のファイル サーバーを構築して社内で共有するファイルやフォルダーをホストしているでしょう。こうした共有されているデーターは会社の資産であり、重要なものとして保護する価値があります。この保護は一般的な情報セキュリティの CIA=「機密性」(Confidentiality)、「完全性」(Integrity)、「可用性」(Availability)を確保するということです。

Windows Server で構築されたファイル サーバーでは、機密性については ACL によるアクセスコントロールやファイルの暗号化(EFS)・ディスクの暗号化(BitLocker)、Windows 情報保護(WIP)などの多くの機能が提供されていますし、サードパーティー製のソリューションもよく利用されています。完全性と可用性の確保で一番ポピュラーなのはデータのバックアップでしょう。これも標準機能・サードパーティー製ソリューションともに幅広く利用されています。またストレージの冗長化も完全性や可用性の確保に RAID などが多く利用されている方法です。

とりわけ可用性の確保では、ストレージを冗長化することが(ディスクが HDD であれ SSD であれ寿命のそう長くないパーツである以上)非常に有効ですが、物理的にデータを保持するストレージではなく、そのストレージを接続し論理的に共有リソースとしてホストするファイル サーバーの冗長化はどのように行うことができるでしょうか。

ファイル サーバーを冗長化する場合、以下のような機能が必要になります。

  • クライアントからは冗長化されたどのサーバーに対しても同一の方法(パス)でアクセスできる
  • 冗長化されたすべてのサーバーは常に同一内容のデータを共有ファイルとしてホストする
  • 冗長化されたサーバーの一部が停止しても、データーの完全性と可用性は損なわれない

こうした条件を Windows Server のファイル サーバーで満たすことができる機能として、以下のような方法が考えられます。

  • Windows Server フェイルオーバー クラスタ(WSFC)を構成する
  • DFSR を利用する
  • 記憶域レプリカを利用する

それぞれの特徴を簡単にまとめて見ました。

Windows Server フェイルオーバー クラスタ

Windows Server フェイルオーバー クラスタは Windows Server の標準機能です。複数のサーバーをクラスタ化し、共有のストレージ(SAS / Fiber Channel / iSCSI)を利用してファイル共有を提供します。動作的には参加しているすべてのサーバーは常時 Active になります。
共有リソースを保持するストレージは共有されますので、ストレージ自体の冗長性確保は別に考える必要があります(基本的に冗長構成が必須)。

2 ノード クラスター
図:https://docs.microsoft.com/ja-jp/windows-server/failover-clustering/deploy-two-node-clustered-file-server より引用

Pros

  • 多数のサーバーをクラスタリングすることで堅牢な冗長性を確保できます
  • Active Directory に依存しない機能なのでワークグループ クラスターを作成できます(ただしファイルサーバーとしての利用は非推奨)

Cons

  • 共有ストレージの要件(SAS / Fiber Channel / iSCSI)のハードルがやや高くなります
  • クラスタに参加するサーバーは同一または類似している必要があります
  • 構成の難易度が相対的に高くなります

参考情報

DFSR

Windows Server の標準機能である DFS 名前空間で作成されたターゲット フォルダー間を自動的にレプリケートする機能です。DFS 名前空間とは複数のサーバー上に配置されている共有フォルダーを、論理的に構造化された 1 つ以上の名前空間にグループ化できる機能で、ユーザーに対して共有フォルダーを仮想化し、複数のサーバー上にあるファイルに 1 つのパスアクセスできるものです。
動作的には DFS を構成するすべてのサーバーは Active に動作します。共有リソースを保持するストレージはサーバーごとに個別に接続されるので、サーバー単位で冗長構成を取らなくとも全体としてはデーターの冗長化が行えています。サーバー間の同期はフォルダー単位でファイル ベースで行われます。

DFS 名前空間のテクノロジ要素
図:https://docs.microsoft.com/ja-jp/windows-server/storage/dfs-namespaces/dfs-overview より引用

Pros

  • 構成が容易です
  • 特別なハードウエアやネットワークを必要としません
  • サーバーやディスクのスペックはまちまちでも問題ありません
  • クライアントからは単一の記憶域として扱えます
  • 障害時の対処が単純(フェールオーバーの操作が必要なく、障害サーバーを復旧させるだけ)です
  • Windows Server Standard 以上のエディションで利用可能です

Cons

  • Active Directory が必須です
  • DFS 名前空間の動作原理上、クライアントがどの物理サーバーにアクセスするか明示的に制御できません(Active Directory サイトの構成によりある程度は制御可能
  • フォルダー間のレプリケートはクライアントからのアクセス(書き込み)とは非同期に行われるため、複製フォルダー間の常時整合性は保証されません(変更が検知されたファイルはいったんステージング領域にコピーされ、その後ネットワーク経由で他のサーバーに同期されます)。そのため同一のファイルが複数のサーバーで頻繁に更新される場合、競合によるデーターの損失や破損が生じる場合があります。

DFSRの参考情報

記憶域レプリカ

記憶域レプリカは障害復旧用にサーバーまたはクラスター間でボリュームのレプリケーションを行う Windows Server の機能です。レプリケーションは同期レプリケーションと非同期レプリケーションが選択できます。機時間の短いネットワーク内でデータをミラーリングし整合性の維持を図るには同期レプリケーションを、遠隔地間など待機時間の長いネットワークを通じてデータをミラーリングする場合は(整合性は保証されませんが)非同期レプリケーションを選択できます。サーバーは Active / Standby の構成(レプリケートされる側を待機系にする)も可能です。サーバー間の同期はボリューム単位でブロック ベースで行われます。
※記憶域レプリカはサーバー間でのレプリケーション以外に、クラスターのノード(群)間、クラスター間でのレプリケーションが可能です。(下図はサーバー間構成例)

施設 5 のサーバーを施設 9 のサーバーでレプリケートしていることを示す図
図:https://docs.microsoft.com/ja-jp/windows-server/storage/storage-replica/storage-replica-overview より引用

Pros

  • 構成が比較的容易です
  • 特別なハードウエアやネットワークを必要としません
  • サーバーやディスクのスペックはまちまちでも問題ありません
  • レプリケートを同期実行できるので、複製間の整合性が高く障害時のファイル システム レベルでのデータ損失もゼロになります

Cons

  • Active Directory が必須です
  • 障害時のフェールオーバーを手動で行うか、自動化する仕組みを作る必要があります(レプリケートするサーバー上のフォルダーをターゲットにする DFS 名前空間を構成して、DFSR ではなく記憶域レプリカで同期する構成にすることは可能です)
  • Windows Server 2016 以前では Standard エディションでは利用できません(Data Center エディションが必要。Windows Server 2019 では Standard エディションでも一部制限付きですが利用可能)

記憶域レプリカの参考情報

まとめ

ミッションクリティカルで堅牢生・高可用性を必要とする場合は WSFC を利用するのが望ましいでしょう。ただし構築に必要なハードウエア費用や技術的コストは相対的に高くなります。

DFSR の良い点は、遠隔地のサーバー間など帯域や遅延に制限のある環境でもクライアントからのアクセスのパフォーマンスに影響を与えることなく同期が行えることです。また同期するグループに何台でもサーバーを追加できる点や構成が用意である点もメリットでしょう。参照が中心のデーターをホストするファイル サーバーを(場所的にも)広範囲で冗長化するのに向いていると思います。

記憶域レプリカは1対1のレプリケーションとなる点が制約です。DFSR のように3台以上のサーバーを同期させることはできません。その代わり同期レプリケーションが可能なので、DFSR のようなデーターの破損や競合の発生は生じません。複数のクライアントから頻繁に更新されるデーターを多数持つファイルサーバーの冗長化に向いていると思います。

ファイルサーバーの冗長化を検討される機会があれば、以上の内容を参考にしてください。

2019年8月3日

Azure Virtual Machine の複製

Filed under: Microsoft Azure — タグ: , , , , , , , — hebikuzure @ 5:00 PM

仕事で Microsoft Azure 上に作成された仮想マシンを複製する方法について調べたので、その記録として記事を投稿します。なおこの記事では ARM(Azure Resource Manager)の仮想マシンを対象としています。クラシックモデルの仮想マシンの場合はこれと異なりますので、ご注意ください。

またこの記事は執筆時点(2019/8/3)の Microsoft Azure の機能と動作に基づいて記述しています。今後機能や動作、画面の変更が行われる可能性がありますので、実際に記事を参考にした操作を行われる場合は最新の情報をご確認ください。

操作手順で示したほとんどの作業は PowerShell でも行えます。またPowerShell での作業は Azure ポータルの Cloud Shell で実行できます。PowerShell での操作については参考資料を参照してください。

複製を作る4つの方法

Azure 上で仮想マシンの複製を作ための機能として公式にサポートされるものとしては、以下の4つが考えられます

  1. 仮想マシンの「キャプチャ」
  2. 仮想ディスクの「スナップショット」
  3. Azure Backup
  4. Virtual Machine Scale Set

それぞれ一長一短なのですが、この記事では汎用性の高い「1.」と「2.」の方法についてまとめています。

実際に複製を行うために、まず実験用の仮想マシンを用意しました。複製対象となるデータ量を小さくするため、CentOS の仮想マシンを作成し、Apache と PHP をインストールしました。

clip_image001

image

clip_image001[5]

仮想マシンのキャプチャから複製する

仮想マシンのキャプチャを行うと「イメージ」リソースが作成されます。イメージには作成元の仮想マシンに接続されていた OS ディスクと(存在すれば)データディスクが含まれています。そのため作成されたイメージから仮想マシンを作成すると、データディスクも含めて元の仮想マシンと同じディスク構成とすることができます。

ただしイメージから新規の仮想マシンを作成するには、キャプチャした仮想マシンの OS が「一般化」されている必要があります。「一般化」とは、Windows でいえば sysprep.exe /generalize を実行することで、デバイスにインストールされたオペレーティングシステムの固有情報(Windows で言えば SID やホスト名などの情報)を消去し、インストール初期でこれらの固有情報が設定される前の状態に戻すことです。これにより、イメージから仮想マシンを作成する際に固有情報の設定の処理が行われ、作成された仮想マシンのオペレーティングシステムはキャプチャ元の仮想マシンのオペレーティングシステムとは別の固有情報を持った別の環境となります。

※上記のように複製を目的としたキャプチャを行うためには一般化が必要となるため、キャプチャ後の(元の)仮想マシンを起動してもキャプチャ前と同様に動作させることができません。そのためキャプチャの操作ではキャプチャ後に元の仮想マシンを自動的に削除することも可能です。また元の仮想マシンをキャプチャ後も稼働させたい場合は、次に示すスナップショットから複製する方法で一般化前の仮想マシンのすべてのディスクのスナップショットを作成しておき、元の仮想マシンの一般化とそれに伴うシャットダウンが完了した後で、スナップショットから仮想マシンを復元することができます。

キャプチャを利用した仮想マシンの複製の手順は以下の通りです。

  1. 複製する仮想マシンの OS を一般化します。
    Windows の場合はリモートデスクトップ接続し、以下のコマンドを管理者権限で実行します。実行後、仮想マシンがシャットダウンされるまで待ちます。
    sysprep.exe /generalize /shutdown /oobe
    Linux の場合は SSH 接続したコンソールで以下のコマンドを実行します。
    sudo waagent -deprovision+user
    確認メッセージが表示されるので注意事項を確認のうえ、「y」 と入力して続行します。
  2. Azure ポータルで複製する仮想マシンを停止(割り当て解除)します。
  3. Azure ポータルで複製する仮想マシンのブレードの[概要] タブの [キャプチャ] をクリックします。
    image
  4. 「イメージの作成」が表示されます。
    必要であれば [名前] [リソースグループ] を変更します。またキャプチャのために一般化した仮想マシンは起動して利用できないので、再度キャプチャすることがなければ [イメージの作成後、この仮想マシンを自動的に削除します] のチェックを付けます。
    最後に確認のため仮想マシン名を入力し、[作成] をクリックします。
    image
  5. 作成が完了したら、イメージを作成したリソースグループを開いてイメージが表示されることを確認します。
    image
  6. イメージ名をクリックしてブレードを開きます。
    image
  7. [+VM の作成] をクリックして、イメージから新しい仮想マシンを作成します。
    [イメージ] の欄に作成したイメージ名がが設定されています。
    image
  8. Market Place から仮想マシンを作成するのと同様に、仮想マシン名、仮想マシンのサイズ、管理者アカウント、受信ポート規則を指定します。
    image
  9. 通常通り仮想マシンの作成を進め、デプロイが完了するのを待ちます。
    image
  10. デプロイが完了したら、[リソースに移動] をクリックして新しく作成した仮想マシンのブレードを開きます。
    オペレーティングシステムは複製元の仮想マシンと同じですが、コンピューター名は新しい仮想マシンの作成時に指定した名前になっています。
    管理者アカウントも同様に新しいものになっています。
    image
    image
  11. 複製した仮想マシンで Apache と PHP が稼働していることを確認できます。
    imageimage

 

仮想ディスクのスナップショットから複製する

仮想ディスクのスナップショットを行うと「スナップショット」リソースが作成されます。スナップショットは採取元の仮想ディスクの内容の読み取り専用の完全なコピーです。スナップショットから(読み書き可能な)仮想ディスクを作成することができ、その仮想ディスクから仮想マシンを作成することができます。ただしスナップショットには採取元の単一のディスクの情報しか含まれていないので、データディスクが接続されていた仮想マシンの場合、複製を行うにはすべてのディスクについて個別にスナップショットの作成と仮想ディスクの作成を行い、OS ディスクから仮想マシンを作成する際にデータディスクを元通りに接続する必要があります。

※スナップショットはディスクが仮想マシンに接続されており、かつ仮想マシンが起動している状態でも採取することは可能です。しかし上に述べた理由から、データディスクが接続されている仮想マシンをスナップショットを使って複製する場合は、仮想マシンを停止した状態でスナップショットを採取する必要があります。そうしないと、OS ディスクを含む複数のディスク間で整合性が取れなくなり、複製した仮想マシン(のオペレーティングシステムやアプリケーション)が正常に動作しなくなる可能性があります。

またスナップショットから仮想マシンを複製する場合は、複製元の仮想マシンのオペレーティングシステムの一般化は必要ありません。ただし一般化を行わず複製した場合は元の仮想マシンの完全なクローンとなるため、同一のネットワーク上で同時に起動した場合、予期せぬ問題が発生する場合があります。一般化後に OS ディスクのスナップショットを採取し複製した場合は、複製後の仮想マシンのオペレーティングシステムはキャプチャ元の仮想マシンのオペレーティングシステムとは別の固有情報を持った別の環境となります。一般化するかどうかは複製後の利用目的に合わせて判断してください。

スナップショットを使った仮想マシンの複製の手順は以下の通りです。

  1. 仮想マシンをシャットダウンします。シャットダウンしていなくてもスナップショットを採取することは可能ですが、仮想マシンの複製に利用する場合はシャットダウン状態の方が無難でしょう。
  2. Azure Portal 複製をで作成したい仮想マシンのブレードを開き、[ディスク] をクリックします
    image
  3. スナップショットを採取するディスクをクリックします
  4. [+スナップショットの作成] をクリックします
    image
  5. スナップショットに名前を付けて、[作成] をクリックします。
    image
  6. スナップショットを作成したリソース グループを開くと、スナップショットが作成されています。
    image
  7. クリックしてブレードを開くと、[エクスポート] という項目があります。これをクリックすると、スナップショットを VHD としてローカルにダウンロードできます。
    ダウンロードした VHD はローカルの Hyper-V で利用する、別サブスクリプションの Azure にアップロードして利用するなどが可能です(OS ディスクであれば VHD を元に仮想マシンを作成することも可能です)。
    image
  8. スナップショットから管理ディスクを作成します。Azure ポータルで [+リソースの作成] をクリックし、検索ボックスに “Managed Disks” と入力して管理ディスクの作成画面を呼び出します。
    image
  9. [作成] をクリックし、管理ディスクを作成します。「リソース グループ」と「地域」をスナップショットを作成したときと同じにしてください。
    [ソースの種類] で「スナップショット」を選択し、採取したスナップショットを選択します。
    ※[サイズ] でディスクのサイズが変更できます。元のディスクより小さいサイズに変更できますが、実際のデータ サイズよりディスクのサイズが小さいとディスクの作成に失敗しますので、注意してください。元のディスクと同じサイズを選択するのが無難でしょう。
    image
  10. [確認および作成] をクリックし、[作成] をクリックするとデプロイが開始されます。
    image
  11. デプロイが完了したら、[リソースに移動] をクリックして新しく作成した管理ディスクのブレードを開きます。
    image
  12. [+仮想マシンの作成] をクリックして、管理ディスクから仮想マシンを作成します。
    [イメージ] の欄に作成元の管理ディスクが設定されています。
    image
    管理ディスクから直接仮想マシンを作成しているので、Market Place やイメージから仮想ディスクを作成する場合と異なり管理者アカウントを指定する欄がありません。
    image
  13. [確認および作成] をクリックし、[作成] をクリックするとデプロイが開始されます。
    image
  14. デプロイが完了したら、[リソースに移動] をクリックして新しく作成した仮想マシンのブレードを開きます。
    コンピューター名や OS の種類が複製元の仮想マシンと同一になっています。管理者アカウントも元の仮想マシンと同じです。
    image
  15. 複製した仮想マシンで Apache と PHP が稼働していることを確認できます。
    image
    image

まとめ

Azure の仮想マシンを複製する方法として、以下の2つについて手順を検証・紹介しました。

  • 仮想マシン一般化した上でキャプチャしてイメージを作成し、イメージから新しい仮想マシンを作成する
  • 仮想ディスクのスナップショットを作成し、スナップショットから管理ディスクを作成し、管理ディスクから新しい仮想マシンを作成する

それぞれ次のような特徴があります。

キャプチャを使う

  • オペレーティングシステムが一般化されるので、元の仮想マシンとは別の環境となる
  • Market Place から仮想マシンを作成する場合と同様に新しいコンピューター名や管理者アカウントを構成できる
  • 一般化が必要なので元の仮想マシンは利用できなくなる

スナップショットを使う

  • オペレーティングシステムの一般化が必要ないので、元の仮想マシンの完全なクローンが作成できる(一般化しても良い)
  • クローンなので新しい仮想マシンのコンピューター名や管理者は元の仮想マシンと同じになる
  • 一般化しなければ元の仮想マシンも利用可能だが、同時利用には注意が必要

参考資料

WordPress.com で無料サイトやブログを作成.

%d人のブロガーが「いいね」をつけました。