Windows Server 2003 R2 – 2008 R2のAMIがアップデートされました。

AWS forumでアナウンスされたとおり、Windows Server 2003 R2, 2008および2008 R2の各バージョンのAMIがアップデートされています。

https://forums.aws.amazon.com/ann.jspa?annID=1897

アップデートされたあたらしいAMIでは、Citrixのpara-virtualized (PV)ドライバが追加されており、これによりWindows Server 2012をふくむすべてのOSでこのPVドライバが使用できることになりました。このPVドライバを使用することで、以下のようなメリットをえることができるようになります。

  • どのインスタンスタイプでもすべてのWindows Server AMIを起動することが可能
  • マウント可能なEBSボリュームの上限が25個に(試験にでるかも!?)
  • ネットワークの信頼性とパフォーマンスの向上
    また、CloudFormationやAWS Tools for Powershellなど展開の自動化に対応したツールがAMIにふくまれています。というわけで、さっそくあたらしいAMIからインスタンス起動してみました。ここで起動に使用したAMIは、Windows_Server-2008-R2_SP1-Japanese-64Bit-Base-2013.03.14 (ami-adba3aac)です。デバイスマネージャーからドライバを確認すると、「ディスクドライブ」「ネットワークアダプター」「記憶域コントローラー」などにCitrix PVドライバを使用していることが確認できました。

    このように、あたらしくなったWindows AMI、ぜひおためしください!

image

Windows Server 2012インスタンスのAMIがアップデートされました

Amazon EC2で提供されている、Windows Server 2012インスタンス用のAMIがアップデートされています。あたらしいAMIは、たとえば「Windows_Server-2012-RTM-Japanese-64Bit-Base-2013.02.13」のように日付がついていますのでCommunity AMIsから検索すると見つけられると思います。

image

あたらしいAMIからインスタンス起動してみたところ、一見あまりこれまでとちがいはありませんがこれまでのセキュリティアップデートが適用されているだけでなく、EC2 Config Servicesのバージョンが2.1.12.0にアップデートされていました。

image

ものすごい細かいところですが、「Administrator Password」の注意書(NOTE以下)の文面が以前のものと多少変わっていることに気づきました。ですが、おそらくこのあたりの動作には変更ないと思います。

image

ということで、今後Windows Server 2012インスタンスを起動する場合はこちらのAMIを利用していただくのがよいと思います。では!

RD Gateway経由でAmazon EC2のWindowsインスタンスに接続してみる

通常、EC2 Windowsインスタンスに接続するためには、通常リモートデスクトッププロトコル(RDP)を使用します。RDPはデフォルトではTCPポートの3389番を使用しているため、ファイヤーウォール経由での接続ではこのポートをオープンしておく必要があります。しかし、企業のファイヤーウォールなどではセキュリティ上の理由などからなかなかRDPのポートをオープンすることがむずかしいと言われることがありました。そこで、リモートデスクトップゲートウェイ(RD Gateway)経由でSSL(HTTPS)を使用してWindowsインスタンスに接続できるかどうかためしてみました。

まず、RD Gateway用のWindowsインスタンスを立ち上げてElastic IPアドレス(EIP)を割り当てておきます。このとき、RD Gateway用のWindowsインスタンスにはまだ通常通りリモートデスクトップ接続を使用して接続する必要があります。サーバーマネージャーから、「役割の追加」を選択して役割の追加ウィザードを開始して、役割として「リモートデスクトップサービス」を追加します。

image

「役割サービスの選択」では、「リモートデスクトップゲートウェイ」のみにチェックをつけて次に進みます。ほかの役割サービスについてはチェックする必要はありません。

image

リモートデスクトップゲートウェイの前提として、「Webサーバー(IIS)」と「ネットワクポリシーとアクセスサービス」、「リモートサーバー管理ツール」が必要になることがわかります。「必要な役割サービスを追加」をクリックすることで、これらの役割サービスをまとめてインストールすることができます。

image

SSL暗号化用のサーバー認証証明書の選択を行います。外部の証明機関(CA)で発行された証明書がある場合は、ここでインポートすることができます。あるいは、SSL暗号化用の自己署名証明書を作成することもできますが、どちらの場合でも証明書のサブジェクト名はこのサーバーのFQDNと一致している必要があることに注意してください。ここでは、「SSL暗号化の証明書を後で選択する」を選択して次に進みます。

image

RDゲートウェイの承認ポリシーの作成を行います。リモートデスクトップの接続承認ポリシー(RD CAP)では、RD Gatewayサーバーに接続できるユーザーを指定することができます。また、リモートデスクトップのリソース承認ポリシー(RD RAP)では、RD Gatewayを経由して接続することのできるサーバーを指定することができます。RD Gatewayを構成するためにはRD CAPとRD RAPの両方のポリシーを作成する必要がありますので、ここでは「今すぐ作成する」を選択して次に進みます。

image

デフォルトでは、AdministratorsグループのみがRD Gatewayに接続できるようになっています。Windowsインスタンスへの管理用リモートアクセスの場合、このままの設定で十分かと思いますので、そのまま次へ進みます。

image

続いて、RD CAPの名前を入力します。ここでは、デフォルトで表示される名前をそのまま使用しています。また、Windows認証方法としてパスワードのほかにスマートカードも使用することができるようですが、ここではパスワードのみにチェックをつけて次に進みます。

image

さらに、RD RAPを作成します。ここでは、RD RAPの名前はデフォルトのまま、「ユーザーがネットワーク上の任意のコンピューターに接続できるようにする」

image

ここまでのインストールオプションを確認して、「インストール」をクリックするとRD Gatewayのインストールが開始されます。インストールの完了後に、インスタンスの再起動が必要になる場合があります。

image

RD Gatewayのインストールが完了すると、サーバーマネージャーで以下のように表示されます。この状態ではまだサーバー証明書がインストールされていないため、いまから証明書のインストールを行います。まず、「操作」から「プロパティ」をクリックします。

image

以下のような画面が表示されますので、「自己署名証明書を作成する」「証明書の作成とインポート」を選択します。

image

証明書の名前を入力します。ここで入力する名前は、RD Gatewayを動かしているWindowsインスタンスのFQDNと一致している必要があります。そのため、ここではインスタンスに割り当てたEIPをDNSに登録したFQDNと同じ名前を入力します。「ルート証明書を格納する」にチェックがついていると、ルート証明書がファイルとして保存されます。サーバー側での作業はこれで完了です。

image

次に、クライアント側でRD Gatewayに接続する前に、ルート証明書のインストールが必要になります。先ほど作成したルート証明書のファイルをクライアントにコピーして、ダブルクリックすると、以下のような画面が表示されます。まず、「証明書のインストール」をクリックします。

image

「証明書のインポートウィザード」で、証明書ストアを選択します。「証明書の種類に基づいて、自動的に証明書ストアを選択する」を選択して次へ進みます。

image

「証明書ストアの選択」で、「信頼されたルート証明機関」を選択して「OK」を推します。

image

以下のようなセキュリティ警告が表示されますが、ここではそのまま「はい」をクリックして先に進みます。ウィザードを完了させると、ルート証明書のインストールは完了です。

image

クライアントでリモートデスクトップ接続を起動して、「詳細設定」タブの「任意の場所から接続する」の「設定」をクリックすると、以下のような画面が表示されます。接続設定で「次のRDゲートウェイサーバー設定を使用する」に、RD GatewayのFQDNを入力します。また、「リモートコンピューターにRDゲートウェイの資格情報を使用する」のチェックをはずしておきます。

image

ここまでで、必要な設定はすべて完了です。実際に、WindowsインスタンスにRD Gateway経由でログオンしてみましょう。RD Gatewayを経由することによって、以下の例のようにEIPをもたないVPC内のインスタンスに対してもリモートデスクトップ接続でログオンできるようになります。

image

まず、RD Gatewayサーバーに対する認証が必要になりますのでAdministratorのユーザー名およびパスワードを指定してログオンします。

image

続けて、ログオンしたいWindowsインスタンスへの認証を行います。該当するWindowsインスタンスの管理者パスワードを入力して「OK」をクリックすると、Windowsインスタンスへのログオンが完了してデスクトップ画面が表示されるはずです。

image

Windowsの認証を二回行わなくてもすむようにするためには、VPC内にActive Directoryドメインをたててあげるといいと思います。

RD Gatewayを使用することによって、HTTPSを使ったWindowsインスタンスへのログオンや、EIPをもたないVPC内のインスタンスに対してのリモートデスクトップ接続ができるようになります!また、SSL証明書を使用することでよりセキュアな接続が可能になりますが、ルート証明書およびパスワードの管理はくれぐれも厳密に行うようにしてください。

AWS上のWindowsインスタンスにWordPressをインストールしてみる ~その2 EC2 + RDS for MySQL環境でのインストール~

前回は、同一のWindowsインスタンスにPHP、MySQLおよびWordPressをインストールしました。しかし、この方法ではMySQLだけを別なサーバーにインストールすることができませんでした。ということで、インストールをはじめからやりなおしましょう。あらかじめ、RDS for MySQLでインスタンスを立ち上げておきます。EC2でWindowsインスタンスを起動し、先ほどと同じくWeb Platform Installer 4.0をインストールします。まずはWindowsインスタンスにPHPをインストールしましょう、「製品」のタブから、「PHP 5.4.9 (英語)」を「追加」して、「インストール」をクリックします。

image_thumb[18]

PHPをインストールすると、IISも同時にインストールされて構成されることがわかります。そのまま、「同意する」をクリックしてインストールを開始します。インストール中にWindows Azureの(以下略)。

image_thumb[20]

インストールが完了すると、以下の画面が表示されますので「完了」をクリックしてWeb Platform Installer 4.0の画面を閉じます。

image_thumb[22]

続けて、WordPress日本語版をダウンロードします。http://ja.wordpress.org/より、WordPress 3.5をダウンロードすることができるようになっていますので、Windowsインスタンス上でダウンロードし、zipファイルを解凍して「wordpress」ディレクトリをそのままIISのWebサイトルート(デフォルトではC:\inetpub\wwwroot)にコピーしましょう。そしてブラウザからhttp://<public DNS>/wordpress/にアクセスすると、こんな画面が表示されると思います。wp-config.phpファイルが存在しないため、これを作成する必要があるようです。まずは、「設定ファイルを作成する」をクリックして次の画面に進みます。

image_thumb[25]

wp-config.phpファイルを作成するためには、wp-config-sample.phpファイルをもとに必要な情報をエディタで編集するかこの自動ファイル生成を使用します。「さあ、始めましょう」をクリックします。

image_thumb[27]

「データベース名」「ユーザー名」「パスワード」「データベースのホスト名」をそれぞれ入力します。ここでは、RDS for MySQLでインスタンスを作成するときに設定したデータベース名、ユーザー名およびパスワード、そしてRDSのエンドポイントを入力して「送信」をクリックします。

image

すると、「wp-config.phpファイルに書き込むことができません」というメッセージが表示されます。ここにwp-config.phpファイルに必要な情報がすべて記載されていますのでWindowsインスタンスでメモ帳などのエディタを開き(しかしながら、メモ帳の使用は推奨されていないようです)、内容をそのままコピー&ペースとしてwp-config.phpファイルをWebサイトルートにあるwordpressフォルダ(デフォルトではC:\inetpub\wwwroot\wordpress)以下に作成してから「インストール実行」をクリックします。

imageあとは、通常通りWordPressのインストールを完了してすぐにWordPressを使いはじめることができるようになります。EC2 + RDSによるWIMPスタックでのWordPressのインストール、いかがだったでしょうか?思ったよりかんたんに環境構築できることがおわかりいただけたのではないでしょうか。WordPress以外にも、いろいろためしてみるとよさそうですね!

AWS上のWindowsインスタンスにWordPressをインストールしてみる ~その1 同一サーバーへのPHP + MySQLのインストール~

Amazon EC2 + RDSのWIMPスタックにWordPressをインストールしてみたので、ここに手順を共有しておきたいと思います。みなさんは、WIMPスタックという言葉をご存知でしょうか。WIMPとは、Windows+IIS+MySQL+PHPの略で、LAMP(Linux+Apache+MySQL+PHP)スタックにならって名づけられた言葉、らしいです。マイクロソフトによると、以下のように定義されています。

サーバー OS には Windows Server、Web サーバーには IIS、データ ベースには MySQL などのオープン ソース DB、開発言語には PHP/Perl/Python。Web アプリケーションを構築する環境において、従来の LAMP (Linux/Apache/MySQL/PHP) に匹敵する新たなソフトウェアの組み合わせです。

今回はこの環境の上で、WordPressをインストールしてみましょう。ちなみに、PHP on IISの情報はこちら(http://technet.microsoft.com/ja-jp/ee794964.aspx)などにまとまっていますので参考にしてみてください。

さて、WordPressのインストールはWeb Platform Installerをつかうと便利です。現在の最新バージョンであるWeb Platform Installer 4.0は、こちら(http://www.microsoft.com/web/downloads/platform.aspx)から無償でダウンロードすることができます。Web Platform Installer 4.0をダウンロードしてインストールすると、こんな画面が表示されるはずです。「製品」および「アプリケーション」のタブをクリックしてみると、本当にさまざまなソフトウェアがここからインストールできることがわかると思います。

image

ここからWordPressをインストールするには、「アプリケーション」タブから「ブログ」を選択して、「WordPress Japanese Package」を「追加」、そして「インストール」をクリックします。

image

このインストーラーでは、データベースの種類が選べませんでしたので、「MySQL (未インストール)」のままrootのパスワードを設定しておきます。

image

インストールされるパッケージの種類を確認して、「同意する」をクリックすると、PHPやMySQLなど必要なパッケージのダウンロードとインストールまで自動的に完了しますのでとっても便利です。インストール中にWindows Azureの広告が表示されたりしますが、とくに気にしなくてもだいじょうぶです。

image

前提となるコンポーネントのインストール後に、WordPressを動かすWebサイトの構成をします。とくにこだわりなどなければ、「Default Web Site」のままでもかまいません。「続行」をクリックするとそのまま次の画面に進みます。

image

この画面では、パスワードを強化するためのユニークキーを設定することができるようになっています。てきとうなフレーズを入力して「続行」をクリックすると、WordPressのインストールが開始されます。Windows Azureの広告が表示されるかもしれませんが、とくに気にしなくてもだいじょうぶです。

image

WordPressのインストールが完了すると、以下のように表示されます。データベース名およびデータベースユーザー名、データベースパスワードが表示されていますのでわすれずにコピーしておいてください。

image

あとは、http://<public DNS名>/wordpress/にブラウザでアクセスすることによってWordPressの構成をはじめることができます。ですが!大事なことをひとつわすれていました。実は、Web Platform Insteller 4.0を使用したWordPressのインストールでは、同一のサーバーにMySQLをインストールしてしまうためAmazon RDSのMySQLをデータベースとして構成することができません。ということで、次回に続きます。

AWS Storage Gateway for Amazon EC2をつかってみる

AWS Storage Gatewayは、これまでオンプレミスのデータセンターに仮想アプライアンスとして設置することでオンプレミスのデータをAmazon S3にバックアップまたは格納することができるサービスとして提供されていました。2012年の10月には、Gateway-Cached Volumeの機能を追加したことにより、最大32TBまでのボリュームをS3上に作成してiSCSIによってアタッチすることができるようになりました。このたび、AWS Storage Gateway for Amazon EC2をリリースをしたことにより、オンプレミスと同等の環境をEC2上で構築してGateway-Cached Volumesで作成したEBS Snapshotを利用してディザスタリカバリを実現したり、EC2上で大規模なファイル共有を実現したりすることができるようになります。

AWS Storage Gateway for EC2は、AWS Marketplaceからダウンロードすることができるようになっています。まずは、AWS Management ConsoleでAWS Storage Gatewayを選択してみましょう。すると、以下のように「Deploy a new Gateway on Amazon EC2」というメニューが追加されていることがわかります。

image

このメニューをクリックすると、以下のような画面が表示されるようになります。まずは、「Launch Gateway AMI」のリンクをクリックしてみましょう。すると、ブラウザのあたらしいタブが開いてAWS Marketplaceのページが表示され、AWS Storage Gatewayが登録されていることがわかります。

image

AWS MarketplaceのAWS Storage Gatewayのページで、Storage Gatewayをデプロイするリージョンを選択すると1時間当たりの課金が確認できるようになっています。また、「Continue」のボタンをクリックすると先に進むことができます。

image

詳細な設定が必要なときは、「Launch with EC2 Console」を選択することによって通常通りEC2 ConsoleからRequest Instances Wizardを使用して詳細なインスタンス設定を行うことができます。また、適切なEC2 Instance Typeを選択してから「Launch with 1-Click」すると即座にインスタンスを起動することもできるようになっています。

image

そのまま、2~3分ほどまつとEC2上のインスタンスが利用可能な状態になります。インスタンスが利用可能になったら、EC2 Consoleから、AWS Storage GatewayインスタンスのPublic DNS名を確認しておきます。

image

Public DNSの数字で書かれている部分(この場合は、54.248.197.157)が、そのままPublic IPアドレスになります。AWS Storage Gatewayのコンソールにもどって、Public IP Addressを入力し「Proceed to Activation」をクリックすると、Gatewayのアクティベーションを開始することができます。

image

アクティベートを行うAWS RegionおよびGatewayのTimezoneをリストから選択して、Gateway Nameに任意の名前を入力して「Activate My Storage Gateway」をクリックするとアクティベーションは完了するはずです。

image

アクティベーションが完了したら、AWS Storage Gateway for EC2をつかいはじめることができます!Cache StorageおよびUpload Bufferを構成するためには、Storage GatewayインスタンスにEBSボリュームをアタッチしてからAWS Storage Gateway Consoleで「Configure Local Storage」を選択して構成してください。それから「Create Volume」で新規ボリュームを作成すると、以下のようにボリュームが見えるようになると思います。

image

あとは、任意のEC2インスタンスからiSCSIイニシエータをつかってボリュームをアタッチするだけで、耐久性99.999999999%のAmazon S3の領域に対してブロックストレージとしてアクセスできるようになります。ここまでの手順は非常に簡単だと思いますので、ぜひAWS Storage Gateway for Amazon EC2を試してみていただければと思います!

AWSでWindows Server 2012インスタンスをつかってみる ~その3 EBSボリュームと記憶域プール~

Windows Server 2012で追加された新機能のひとつに、「記憶域プール」というのがあります。これは、複数のストレージを組み合わせて、ひとつの大きなストレージとして使用することができる機能です。たとえば、これまでEBSボリュームの最大容量は1TBに限られていました。1TBを超えるボリュームをWindowsから扱う必要がある場合は、複数のEBSボリュームをアタッチしてソフトウェアRAIDを組むことができました。しかし、WindowsのソフトウェアRAIDは障害時の対応やバックアップなど、かならずしも運用が容易でないところがあったのもまた事実かと思います。Windows Server 2012の記憶域プールをつかうとこれがどう変わるでしょうか?ということで、さっそくためしてみたいと思います。

まず、EBSボリュームを作成してWindows Server 2012インスタンスにアタッチします。AWS Tools for Windows PowerShellをつかっている場合、こんな感じになると思います。この例では、10GBのEBSボリュームをap-northeast-1aのアベイラビリティゾーンに作成しています。

PS C:\Program Files (x86)\AWS Tools\PowerShell> New-EC2Volume -Size 10 -AvailabilityZone ap-northeast-1a

VolumeId         : vol-405f9b62
Size             : 10
SnapshotId       :
AvailabilityZone : ap-northeast-1a
Status           : creating
CreateTime       : 2012-12-08T06:21:00.000Z
Attachment       : {}
Tag              : {}
IOPS             :
VolumeType       : standard

作成したEBSボリュームをインスタンスにアタッチするには、以下のように入力します。デバイス名として、xvdfからxvdpまでの名前をつかうことができます。

PS C:\Program Files (x86)\AWS Tools\PowerShell> Add-EC2Volume -VolumeId vol-405f9b62 -InstanceId i-4476f947 -Device xvdf

VolumeId            : vol-405f9b62
InstanceId          : i-4476f947
Device              : xvdf
Status              : attaching
AttachTime          : 2012-12-08T06:38:03.892Z
DeleteOnTermination : False

上記のようにして、複数のEBSボリュームをWindows Server 2012インスタンスにアタッチしてしまいましょう。つぎに、Windows Server 2012の「サーバーマネージャー」から、「ファイルサービスと記憶域サービス」→「ボリューム」→「記憶域プール」を選択します。「物理ディスク」に、EBSボリュームが表示されているのがわかります。

記憶域プール

「Storage Spaces」もしくは「物理ディスク」から、該当するエントリを右クリックして「記憶域プールの新規作成ウィザード」を立ち上げます。まず、記憶域プールの名前に好きな名前をつけて、利用可能なディスクのグループを選択します。そして、記憶域プールに所属させる物理ディスクを選択して、ウィザードを完了させると記憶域プールが作成できます。ここで、PhysicaDiskとして表示されているのがEBSボリュームになります。

記憶域プールの物理ディスクを選択

つぎに、「仮想ディスクの新規作成ウィザード」を起動して仮想ディスクを作成します。先ほど作成した記憶域プールを選択します。また、仮想ディスクに好きな名前を付けておきます。「記憶域のレイアウト」では、Simple、Mirror、Parityの三種類が選ぶことができます。EBSボリュームはそれ自体で冗長化の仕組みが実装されていますので、ここでは「Simple」をえらぶのがいいのではないかと思います。

記憶域のレイアウトの選択

プロビジョニングの種類の指定を行います。プロビジョニングの種類で「最小限」を選択すると、「ボリュームは、ボリュームサイズを上限に、必要に応じて記憶域プールの領域を使用します。」よくわかりませんが、とにかく先に進んでみることにしましょう。

プロビジョニングの種類の指定

ここで、仮想ディスクのサイズで100GBを指定しましたが、記憶域プールの空き領域は18.0GBしかありません。これでだいじょうぶなんでしょうか?と思いますが、問題なく100GBの仮想ディスクが作成できました!さきほどの「最小限」が、ストレージのシンプロビジョニングのような機能であることがこれでわかりますね。

仮想ディスクの新規作成ウィザード

最後に、新しいボリューム ウィザードを使用してボリュームを作成し、ボリューム文字を割り当ててあげると記憶域プールをWindowsのボリュームとして使用することができるようになります。ファイルシステムの選択で、NTFSだけでなくReFSとでてくるのが気になりますが、とりあえず今回は放っておいてNTFSを選んでおきました。

新しいボリュームウィザードを完了させると、以下のように記憶域プールが使えるようになります。使っている途中で容量が足りなくなった場合は、新規にEBSボリュームをアタッチして記憶域プールに割り当ててあげることができます!ご存じのとおり、EBSボリュームはいつでも作成することができて容量当たりの従量課金になりますのでうまく記憶域プールと組み合わせてあげることによってストレージコストの最適化ができると思います。EBSボリュームと記憶域プール。これは、まさに最強の組み合わせと言えるのではないでしょうか?

ディスク