月: 2013年2月

Microsoft SPLA と仮想化について

サービスプロバイダーライセンス (=SPLA) と仮想化環境と組み合わせたときに必要なプロセッサライセンス数を Microsoft に確認する機会があったので、覚書としてまとめておきます。 Microsoft の日本語ページを見てもさっぱりわからないので多少は役に立つでしょう。

今回の記事は Windows Server のプロセッサライセンスと SQL Server のコアライセンスについてです。 ユーザー数に応じた従量課金のサブスクライバーライセンスというのもありますが、サービス提供者からするとプロセッサ／コアライセンスの方が扱いやすいと思います。

ライセンス体系はバージョンによって変更する可能性があるので、最終的にはこの記事を鵜呑みにせずご自身で確認することをお勧めします。 Microsoft パートナーコールセンターに問い合わせると丁寧に教えてもらえます。

プロセッサライセンス

ちょっと前は Server 2008 R2 Enterprise のプロセッサライセンスというものが存在していてその上なら仮想インスタンス (仮想マシン = VM) をいくつまで動かせます、というのがありました。 しかし、現行の Server 2012 版ではこの Enterprise がなくなって Standard か Datacenter かという選択になります。 ライセンス上は Server 2012 ですが、ダウングレードして Server 2008 R2 を使用することができます。 面倒な手続きはなく、後述のプロダクトキーの発行時に 2008 R2 を指定するだけです。

Datacenter を買えば 1物理プロセッサ上であれば VM 数は無制限なのですっきりします。 問題は Standard の場合の考え方です。

今回の例として図のような VMware vSphere HA を使った構成を考えます。 2プロセッサ／台の物理サーバーを 2台使っています。 VM の数は 3つで正常時は 2つの物理サーバーに分散されて配置されます。 白が現在稼動している VM で、破線はフェイルオーバーしたときに動く可能性がある位置を示しています。

VMs

この場合、各物理サーバーで最大 3VM が動くことになります。 各々の物理サーバーで必要なライセンス数はこの最大値である 3VM で数えなければならないとのことでした。 すると 3VM × 2プロセッサで 6 Standard ライセンスが各々のサーバーに必要となります。 従って全体で必要なのは 3VM × 2プロセッサ × 2台で 12 Standard ライセンスとなります。

この構成で 12 なのかあ、という感じですが、SPLA ライセンスは想像よりも安価だったことは付け加えておきます。

ちなみに 6VM／物理サーバーを超えると Datacenter の方がお得になります。 これは Microsoft 説明資料 (英語 PDF)の p.16 にも説明されています。 最初は Standard で始めて後から Datacenter にアップグレードすることも可能とのことでした。 まあ、月額で課金なのでそれができるという話もあります。

英語ならばこの他にもサービスプロバイダー向け資料が整っているので興味があれば見ておくと良いと思います。

SQL Server

Windows Server はプロセッサ数がカウントの対象でしたが、SQL Server の方はコアライセンスとなっていて、CPU のコア数が問題になってきます。 そして仮想環境では SQL Server が稼動する VM に割り当てられている仮想コア数分の Core ライセンスを購入すればよいとのことでした。 ただし、最低が 4コアなので、2コアしか使わなくても 4コア分のライセンスを購入する必要があります。

こちらも HA だと 2倍かと思いきや、Active – Stanby 構成であれば稼動している VM のコア数でよいとのことです。 後から見つけましたが、英語の資料 (PDF) にも書かれています。

キーの発行

プロダクトキーの発行はライセンス認証窓口で行います。 SPLA という案内はないのですが、音声案内でボリュームライセンスの発行を選ぶと受け付けてもらえます。 SPLA 契約番号が必要です。 ちなみに SQL Server の方はプロダクトキーは不要です。

Windows Server 用プロダクトキーに関しては KMS キーと MAK キーの選択が必要です。 私はこの区別がわかっていなくて説明をしてもらう必要がありました。 KMS が使えるのは KMS クライアント 5台 + KMS ホスト 1台 = 計 6台の Windows Server 構成からなので、5台までは MAK キーでの発行となります。 複数の VM に導入する場合も、1つの MAK キーの発行でオッケーとのことでした。

2013.7.11 追記

図と説明で数が合っていなかったので訂正しました。

WordPress のリビジョンに覚書としてメモをつける

手前味噌な話題で恐縮なんですが、WordPress 用プラグインの Thin Out Revisions がバージョンアップして投稿／ページのリビジョンにメモを付けられるようになりました。

Revision Memo

上の画像のように編集画面に新たに「リビジョンメモ」が現れます。 また、「リビジョン」の部分の表示に入力メモが表示されます。

なお、一度入力し確定したメモは修正できません。まあ、リビジョンなんでそういう仕様ということで。 気に入ったら是非 Twitter や Facebook 等で広めてくださいね。

WordPress でのデバッグ用メッセージ出力

WordPress でテーマやプラグインの開発をしているとデバッグ用のメッセージを出力したいときがあると思います。 しかし、リダイレクト関連や Ajax 関連の動きを調べるときなどは簡単に画面出力できません。 そんな時にファイルへ出力するための簡単な方法を紹介します。

wp-confing.php に以下の 2行を入れます。

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);

後は必要なところで PHP 標準関数の trigger_error を呼ぶだけです。

trigger_error('出力したいメッセージ');

すると trigger_error に渡したメッセージが wp-content/debug.log に出力されます。 お手軽ですね。

ただし、この設定だとスクリーンにも表示されるので、ファイルのみに出力したいときは WP_DEBUG_DISPLAY を false に設定します。 参考情報はこちら。

スターウォーズと VRF

togetter で面白いネタを見つけたのですが、まとめられているコメントに微妙なものもあるので、技術的なところを簡単にメモ書きしておきます。 そのネタとは、ある IP アドレス (216.81.59.173) に traceroute をかけると Star Wars のオープニングのテキストスクロール (のパロディ？) が表示されるというものです。 実際に traceroute をかけた時の動画が YouTube にアップロードされていて、技術的な内容はこちらにまとめられています。 なお、有名になったため、(DDoS のものも含め) 大量のトラフィックを受けてしまったようで今も試せるかはわかりません。 少なくとも私の ISP からでは現在到達できないようです。

さて、実際にどうやってこれを実現しているかというと構成要素は二つあって、まず一つは DNS の逆引きを利用しているわけです。 これは 251.214.206.in-addr.arpa ゾーン内の対応する各レコードに表示する内容 (ホスト名) を書いておけばよいわけで、さして難しいことはありません。 以下のような内容が書かれているのでしょう。

1 IN PTR Episode.IV.
6 IN PTR A.NEW.HOPE.
9 IN PTR It.is.a.period.of.civil.war.

もう、一つの構成要素は 251.214.206.0/24 のネットワーク構成になります。 論理的に細かく分けて多くのゲートウェイを通過するようにしなければならないので、DNS レコードの登録よりもこちらの方が面倒くさいと思います。 何も考えずに構成を組むと大量のルータが必要となりそうですが、そこで利用されるのが Cisco ルーターの VRF という機能です。

VRF は簡単に言うと複数のルーティングテーブルを持つ機能です (Cisco の設定例)。 今回は多数の VLAN を作成し、VRF を用いて各 VLAN 固有のルーティングテーブルを設定することで、実際には 2台のルータ間を行き来するだけで多数のゲートウェイを通過するように設定したようです。 先に紹介したページの PHP スクリプトを実行すると 2台分のルータの設定が生成されますが、これを見ると /30 を割り当てた VLAN を 2台のルータに多数作って 216.81.59.173 宛のパケットを 2台の間で行ったりきたりするようになっています。 ですので、見た目よりはずっと簡単な物理構成で実現されています。

こういった遊び心と技術センスは真似してみたいところですね。