特集 Windows Server 2003完全ガイド エンタープライズ環境はこう変わる 2.新しいフォールトトレラント・ハードウェア・コンポーネントのサポート Peter Pawlak2003/09/02 Copyright(C) 2003, Redmond Communications Inc. and Mediaselect Inc |
|
前編では、Windows Server 2003における、高可用性を実現するための新機能について解説した。後編では、フォールト・トレラントと負荷分散機能について見ていく。
■
Windows Server 2003は、ソフトウェア・ベースのディスク・ミラーリングなどのフォールトトレラント・コンポーネントに対する既存のサポートを継続するほか、いくつかの新しい冗長性コンポーネントに対するサポートを追加した。
■ストレージ・エリア・ネットワーク(SAN)マルチパスI/O
Microsoftはストレージ・ハードウェア・ベンダと共同で、ハードウェアに依存しないAPI、マルチパスI/O(MPIO)を定義した。MPIOは、SANデバイス用の冗長なネットワーク・アダプタとネットワーク・パスの使用を可能にする。SAN環境では、サーバとストレージ・コントローラ間の接続は潜在的な障害発生地点である。Windows 2000 Serverでは一部の独自技術のソリューションによって冗長性を提供していたが、Windows Server 2003ではSANベンダの「デバイス専用モジュール(ドライバ)」と連携する共通のMPIOドライバを装備している。共通機能用の一貫性のあるコード・ベースを提供し、各ベンダと連携して、各社のドライバ機能の信頼性を確保する考えだ。
■メモリ・ミラーリング
Windows Server 2003はMarathon TechnologiesやNEC、Stratus Technologiesなどのベンダの特殊なフォールトトレラント・サーバと組み合わせて使用した場合、「メモリ・ミラーリング」機能をサポートする。この機能は冗長サーバへの迅速なフェイルオーバーを可能にする。冗長サーバのメモリは、オリジナル・サーバのメモリを障害が発生するまで継続的に複製する。
クラスタリングの大幅改善
Windowsにおけるクラスタリングのサポートは、Windows NT 4.0以来のものである。しかしWindows Server 2003, Enterprise Editionでは大幅な改良を施し、クラスタをいっそう強化して、より多くのシナリオで役立つようにしている。クラスタ対応のOSサービスの数も増やしている。しかし、基本テクノロジとクラスタAPIはWindows 2000が採用していたものと非常に似ているため、Windows 2000クラスタはWindows Server 2003にノード単位でアップグレードでき、クラスタ全体を停止させる必要はない(3ノードWindows Server 2003クラスタの基本要素の図解は、図「典型的なクラスタ・コンフィギュレーション」を参照)。
最も重要な変更点のいくつかを以下に示す。
■8ノード・サポート
Windows Server 2003 EnterpriseおよびDatacenter Editionは、いずれも8ノード・クラスタをサポートするようになった(Windows 2000 Enterpriseの2ノード、Windows 2000 Datacenterの4ノードから増加した)。これによってクラスタ化したアプリケーションの拡張性が増すわけではないが、小型のクラスタを複数構築する場合に比べ、可用性の向上にかかるコストが削減できる。クラスタの最も一般的なコンフィギュレーションは、クラスタ内の物理的サーバの総数よりも1台少ないアクティブ・ノードを設ける方法だ(残りの1台のパッシブ・ノードはほかの任意のアクティブ・ノードを引き継ぐことができる)。このため、ノード数が増加するとスタンバイ・ハードウェアの比率は下がり、効率が改善される。例えば2ノード・クラスタでは50%のノードがフェイルオーバー用の予備となるが、8ノード・クラスタでは予備は12.5%のノードだけである。各アプリケーション・インスタンスは依然として一度に1つのアクティブ・ノードでしか稼働しないが、8ノードをサポートしたことで多数のアプリケーション(同じアプリケーションの複数のインスタンスでも異なるアプリケーションでも可)をホスティングする単一の大型クラスタの構築が可能になる。
■64bitサポート
非常に重い作業負荷を処理したり、大容量のメモリ(3Gbytes以上)を必要としたり、複雑なクエリを非常に高速に実行する必要のあるWindowsアプリケーション(主にデータベース)は、64bitプロセッサのIntel Itaniumシステム用のWindows Server 2003の恩恵を受けることができる。64bit版Windows Server 2003は兄弟分の32bit版と同じクラスタリング機能をサポートするので、クラスタリングを用いてこれらの64bitアプリケーションの可用性を高めることができる。
■Geoclusterのサポート
Windows Server 2003以前は、クラスタ・ノードは物理的に接近している必要があった。「クォーラム」ボリュームと呼ばれる共有ディスク・リソースへの直接アクセスを必要としたからである。クォーラム・ボリュームはクラスタのコンフィギュレーション情報とステート情報を格納する。クラスタ・メンバーはこれらの情報を用いてどのノードがアクティブかを判断し、障害発生時にはどのノードがアクティブな役割を引き継いで共有ディスク・リソースのコントロールを引き受けるかを判断する。この距離的接近という制約のせいで、Geocluster(ジオクラスタ)の構築は困難だった。Geoclusterとは、クラスタ・ノードがWAN接続された地理的に異なる場所に存在し、SANレプリケーション・テクノロジを用いて共有ディスク・ボリュームを複数のサイトにミラーリングするコンフィギュレーションである。
Windows Server 2003は共有クォーラム・ボリュームの必要性を抑制するマジョリティ・ノード・セットという新メカニズムを導入してGeoclusterの構築を可能にした。しかし、マジョリティ・ノード・セットは「voting」を用いてどのサーバがアクティブでディスク・リソースにアクセスできるかを判断するため、クラスタは最低3個のノードを持つ必要がある。ノード数が少ないと、通信障害によって投票結果が同点となり、クラスタがどのノードをアクティブにすべきかを判断できなくなる可能性がある。
■Active Directory(AD)とKerberosのサポート
Windows 2000はサーバ・リソース検索用のAD、名前解決用のDNS、認証用のKerberosをネイティブでサポートする。しかしWindows 2000クラスタには制約があるため、同じタスクを実行する旧式で機能と安全性の低いプロトコル(具体的にはブラウジングとクラスタ・ノードの名前解決用のNetBIOSプロトコルと、接続を認証するためのNTLMプロトコル)を使用しなければならなかった。
Windows Server 2003ではこうした制約がなくなり、クラスタの仮想サーバは物理的サーバと同様にADおよびDNSエンティティとなる。Kerberosはより複雑なマルチフォレストADアーキテクチャをサポートするので、あるフォレストのユーザーは別のフォレストのクラスタに自身を認証できる。Kerberosは多層アプリケーションのセキュリティをより厳格かつきめ細かくする「偽装(impersonation)」もサポートしている。偽装により中間層サーバは共通のサービス・アカウントの代わりに各接続ユーザーの認証を用い、これらの代行としてバックエンド・サーバにサービスをリクエストできるようになる。従ってユーザーのより限定的なパーミッションだけがクラスタ上にホスティングされたバックエンド・アプリケーションに渡されるようになる。
■メッセージ・キューのサポート
開発者はMicrosoftメッセージ・キュー(MSMQ)を使用してWindows 2000クラスタ仮想サーバに接続するアプリケーションを開発できたが、MSMQ「トリガ」を利用することはできなかった。MSMQトリガとは、COMコンポーネントやスタンドアロンの実行可能ファイルを自動的に呼び出し、受信したキュー・メッセージを処理するメカニズムである。つまり開発者は多数のカスタム・コードを書かなければ、クラスタに受信メッセージに対する操作(ビジネス・ルールの適用など)を行わせることができなかった。
Windows Server 2003クラスタは、いまではMSMQトリガをフル・サポートし、クラスタの仮想サーバがホスティングするキュー情報はADでパブリッシュすることもできる。
■クライアントサイド・キャッシングのサポート
Windows Server 2003クラスタは今回からクライアントサイド・キャッシングをサポートする。このため、ユーザーはWindowsのオフライン・フォルダ機能を使ってクラスタ・サーバ上の仮想サーバ・シェアからファイルを各自のクライアント・コンピュータに複製でき、ネットワークから切断したときにクラスタに常駐する各自のファイルにアクセス可能になる。これにより、クラスタを用いてファイル・サービスをホスティングする場合の深刻な制約が解消される。
■SANサポートの改良
Windows Server 2003には、SAN上でクラスタ・ストレージとクォーラム・ボリュームをホスティングするためのさまざまな改良が施されている。最も興味深いものの1つは、共有ストレージ・バス経由でのSANからのブートをサポートしていることだ。これにより、ハードウェア・ベンダは(一般的に冗長な)SAN接続を用いたクラスタ・システムを構築できる。これは共有クラスタ・ボリュームだけでなく、ノードのOSファイル、ページ・ファイル、アプリケーション・プログラム・ファイル専用のボリュームへのアクセスを実現する。この構成ではローカル・ストレージは不要になり、すべてはSAN上に常駐する。Windowsクラスタ・サービスはさらに、今回からディスク・ボリュームの動的なリサイズをサポートする。これにより、アプリケーションの可用性を中断せずにSANリソースをより効率的かつ柔軟に利用できる。
■開発者サポートの改善
新しい「ジェネリック・スクリプト(generic script)」クラスタ・リソース・タイプにより、開発者はスクリプティング(Microsoft VBScriptやJScript)を用いて、いくつかの既存アプリケーションをクラスタ対応(つまりCluster APIと通信可能)にすることができる。その際、CやC++で特殊なアプリケーション・リソースDLLを書く必要はない。これにより、Windowsクラスタ・サービスと連携するように書かれていないアプリケーションのクラスタ対応が簡略化される。またWindows Server 2003では、開発者は高価なSANがなくても、安価なシングル・ノード・クラスタを構築できる。シングル・ノード・クラスタは冗長性を提供しないが、開発者はより高価なマルチサーバ・クラスタがなくともクラスタ対応アプリケーションの開発やテストを行える。
INDEX | ||
[特集]Windows .NET Server 2003完全ガイド | ||
Windows Server 2003でエンタープライズ環境はこう変わる | ||
1.Windows Server 2003信頼性向上のポイント | ||
コラム:高可用性システムの3つの重要ポイント | ||
コラム:Windows 2003 Datacenterの新機能 | ||
コラム:冗長性を用いて高可用性システムを構築する4つの方法 | ||
2.新しいフォールトトレラント・ハードウェア・コンポーネントのサポート | ||
3.サーバ・ファーム全体のネットワーク負荷分散の改善 | ||
Windows Server 2003完全ガイド |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|