はじめに

AWSの大きなメリットとして「スモールスタートが可能」が歌われています。ストレージの観点で言うと、AWS上の既存インスタンスにEBSを追加したり既存EBSを拡張したりするのは簡単です。したがって、スモールスタートして、ビジネスの拡大に応じてディスク容量を拡張していくのは容易に思えます。ただし、本当に必要なのは、EBSの容量を増やすことではなく、ファイルシステムの容量を増やす事であり、且つ拡張作業をビジネスへの影響を最小限にとどめながら行う事です。特に、クラスタリングされているようなシステムの場合、いかにしてサービスの停止時間をゼロもしくは少なくしながらファイルシステムの拡張が行えるかが重要です。

前述したように、AWS上のインスタンスのストレージ容量を増やす手法は、以下の2種類があります。

１．既存EBSの拡張
２．EBSの新規追加

本記事では、上記2つについて、それぞれの特徴と拡張の際の手法について、クラスター構成である事を前提に説明します。尚、前提となるクラスター構成は以下の図の通りです。

上記クラスター構成の詳しい実装方法については、ベリタスよりホワイトペーパーが公開されています。是非こちらをご覧ください。

既存のインスタンスのEBSを増やす手法毎の特徴

既存EBSの拡張
AWSでは、Windowsインスタンスに関連付けられたEBSを拡張する事ができます。この手法のメリットは、Windowsインスタンスに新たなデバイスを追加する必要が無いので構成変更を最小限に抑えられる事です。デメリットは、EBSの拡張の限界が16Tbyteである事です。

拡張後に必要なEBSの容量が16Tbyte以内で、且つシステム構成への変更を最小限にとどめたい場合は、この方法を用いてください。詳しい作業方法については、ベリタスよりホワイトペーパーが公開されています。是非こちらをご覧ください。

EBSの新規追加
AWSでは、Windowsインスタンスに新たなEBSを追加する事ができます。この手法のメリットは、16Tbyteを超える容量を提供できる事です。デメリットは、新たなEBSが追加されるのでシステムの構成が大きく変更される事と、EBSの追加の限界が26個である事です。

拡張後にインスタンスに接続されるEBSの数が26個以内で、作業に伴うシステム停止が許容できない場合、この方法を用いてください。詳しい実装方法については、ベリタスよりホワイトペーパーが公開されています。是非こちらをご覧ください。

非クラスター構成での対処方法

本記事では、クラスター構成である事を前提としましたが、非クラスター構成でも対処方法は同じです。

おわりに

如何でしたでしょうか？　今回の記事と記事中に紹介したホワイトペーパーによって、AWS上のWindowsでファイルシステムの拡張が必要になった場合の対処が明確になり、スモールスタートを検討する際のハードルはかなり下がったのではないでしょうか？　今回の内容は、ストレージ管理や高可用性に関する様々な顧客要件を満たすInfoScaleのほんの一部をご紹介にしたにすぎません。次回は、Azure上のWindowsでクラスタリングを行う場合の具体的な構築手順をお送りします！

商談のご相談はこちら

本稿からのお問合せをご記入の際には「コメント/通信欄」に#GWCのタグを必ずご記入ください。
ご記入いただきました内容はベリタスのプライバシーポリシーに従って管理されます。

その他のリンク

【まとめ記事】ベリタステクノロジーズ 全記事へのリンク集もよろしくお願いいたします。