複数台のサーバで同一のコンテンツを共有する方法 〜 第1回

複数台のサーバで同一のコンテンツを参照し、配信する仕組みを考えてお試ししてみたいと思います。今回も2〜3回に分けてお届けします。

Azureで提供されているサービスを使い、この要件を満たす方法としては幾つか考えられます。最もお手軽な方法としては、Web AppsとBlob StorageやCDNを使うことだと思います。発射台となるWebサーバをWeb Appsでカバーし、固定的なファイル群を束ねることができます。

このパターンはすぐにできそうなので、今回はもう少し手間のかかる方法を試して比べて見たいと思い、次の2つのサービスを利用してみたいと思います。

  • Virtual Machine Scale Sets
  • Azure Files

なお、作業においてPortalが使えない場合はAzure CLI 0.10.0を利用します。

学ぶ

まずは、Virtual Machine Scale Sets(以下、VMSS)のドキュメントに目を通し、基本的な部分をおさえておきます。

https://azure.microsoft.com/ja-jp/documentation/articles/virtual-machine-scale-sets-overview/

自動的にスケールをする方法については改めて試すことにし、今回は最小限の使い方にしてみます。

次に、Azure Files はこちら

https://azure.microsoft.com/ja-jp/documentation/articles/storage-how-to-use-files-linux/

ようは、VMSSを使ってLinuxサーバを構築し、それぞれにAzure Filesをマウントして同一コンテンツを参照できるようにしようという作戦です。

Linuxを2台作る

作業の参考となるドキュメントはこちらです。

https://azure.microsoft.com/ja-jp/documentation/articles/virtual-machine-scale-sets-linux-create-cli/

こちらではコマンドでの作り方が紹介されています。コマンドとしては azure vmss quick-create となっております。

最初はこちらを使おうかと思いましたが、ポータルにメニューがあるかも調べてみました。

ポータルで新規をクリックし、上部の検索窓に打ち込んでみるとメニューが出てきましたので、こちらでまずはやってみます。

使えそうなので作成をクリック。

まずは仮想マシンを作る時と同じような画面です。マシン名、ユーザー名、パスワードもしくは公開キーなどを設定します。

ちょっと残念なのはOSイメージが少し古いものしか選べない点。これは後で解決策を考えることにします。ここではUbuntu14.04 LTSにしました。 インスタンス数はひとまず2台、マシンサイズはA0でケチりました。

最後に設定全体を確認し、実行します。

ポータル右上のベルマーク、通知にてデプロイが開始された旨が知らせられます。

このデプロイが開始されましたをクリックすると、デプロイの様子を見ることができます。

暫く待つとデプロイが完了します。何が作られたかを確認するため、リソースグループの名前をクリックします。(なお、この画面でデプロイに使われたテンプレートをダウンロードできるので次回以降のためにダウンロードしておきました)

確認すると、標準メニューから実行した場合はこのようなリソースがつくられました。一つ一つ確認してみます。

まずはスケールセット。パブリックIPが1つ表示されます。つまり、全体で1つの外部からアクセスできる入り口を持っていることになります。サイズは指定通りで、自動スケールがオフになっています。

次に、ロードバランサを見てみます。

パブリックIPは先程スケールセットで表示されていたものと同じです。つまり、スケールセット側にはロードバランサに関連付けられたIPが表示されていたことになります。初期状態では負荷分散は動いておりません。意向でhttpなどの通信を振り分けたいときは追加の設定が必要ということになります。 NATが2つ設定されているようです。

プロパティを幾つか確認してみます。まずはバックエンドプール。

2台のVMが作成され、ロードバランサに関連付けられています。

次に、NATの規則です。

確認すると、パブリックIPで受けてPort 50001だった場合は、背後の1台目のサーバのPort 22へフォワードしています。つまり、SSHでサーバへつなぐことができるようになっています。

パブリックIPと仮想ネットワークは割愛します。仮想ネットワークはサブネットが一つ切られており、そこにVMが二台ぶら下がっている状態です。

次に、5つも作成されたストレージアカウントです。

全て確認したところ、5つのストレージアカウントに対し、3つにて スケールセット名+vhd のコンテナが作成され、2つのコンテナ内にVHDファイルが作成されていました。

当記事の冒頭で読んだドキュメントに、VMSSでのストレージアカウントに関する記述がありました。(VM スケール セットのパフォーマンスとスケールのガイダンス、という部分)大規模な構成を組む場合は、ストレージアカウントをどのように使うべきか制約をおさえておくべきでしょう。

動作確認

それでは最後に起動しているVMへ接続してみます。

ここまでの確認でパブリックIPとどのポートに接続すればよいかわかっていますので、迷わず接続しておきましょう。

まとめ

初回はVMSSを軽く試しました。最初からロードバランサーを作ってくれるところや、VMにパブリックIPが付与されないのはセキュリティ的に良いので、複数台を作るケースではこちらを使うほうが良いと感じます。

いくつか追加で調べたいこととしては

  1. オリジナルのイメージでのスケールセットの作り方
  2. 後で台数を変えたい場合のやり方
  3. 可用性セットとの関係性
  4. バックアップはどうするのが良いか
  5. リソース開放してコスト抑えたい

といったあたりと感じました。幾つかはドキュメントがあることが作業中に確認できているので、別の機会でこのあたりは検討したいと思います。

次回は今回作った2台のサーバにAzure Filesをマウントして同一のコンテンツを参照できるか検証してみたいと思います。

おまけ

2台のサーバにそれぞれSSHで繋いで作業するのを楽できないかなと探したところ、psshというものを見つけました。

こんな感じになります。