月: 2020年6月 - IT Fragments

SPDY – WEB高速化のための実験段階のプロトコルSPDYとは何か

訳注

このページの原文はThe Chromium ProjectsさんのSPDY: An experimental protocol for a faster webページです。Attribution 2.5 Generic (CC BY 2.5)ライセンス下のコンテンツとあったので和訳公開します。
なお、素人の意訳なので勘違いや原文と異なる表現もありえます。ご注意ください。

前書き

私たちは「WEBを高速化しよう」という活動の取り掛かりの一つとして、ページ取得にかかる時間を減らすためのいろんな代替えプロトコルを実験しています。その一つがWEB上のデータ転送時間短縮に特化したアプリケーション層のプロトコル SPDY（スピーディと読む）です。

ただプロトコルの策定だけでなく、SPDYが動作するChromeブラウザとオープンソースのWEBサーバを開発しました。研究室のテストでは、HTTPとSPDVの比較で最大64%の読み込み時間短縮を観測しました。このオープンソースコミュニティでのアイデア出し・フィードバック・コーディング・テストへの貢献がSPDYを次世代の高速WEBプロトコルに育ててくれたら幸いです。

背景

今日ではWEBのプロトコルはHTTP＋TCPです。TCPは一意性・データ順序・流れ制御・混雑回避を保証する一般的な信頼できる転送プロトコルです。HTTPは基本的な要求・応答を定義するアプリケーション層のプロトコルです。トランスポート層の改善もありだと思いましたが、まずはアプリケーション層のプロトコル、HTTPに的を絞って改善することにしました。

不幸なことにHTTPは速度重視に設計されていません。さらに今日のWEBページの転送は10年前とは大きく変化し、当時予想されなかった改善が望まれています。次に示すのはHTTPのパフォーマンスを落とす特徴です。１コネクション当たり１リクエストのみ

HTTPは一度に一資源しか取得出来ないため、５００ミリ秒間追加のリクエスト処理を行えません（一応パイプライン化という機能がありますが、それでもFIFO待ち行列を使用せねばならないという制約があります）。この問題があるので、ブラウザは複数のコネクションを張るようになりました。大抵のブラウザは２つのコネクションだった2008年から最終的には６つのコネクションまで推移しました。クライアント側のリクエストが無いと始まらない

HTTPではクライアント側のリクエストが無いとファイル転送を行えません。サーバ側ですでにクライアントの必要なファイルがあると分かっていても、クライアント側の要求を待つ必要があるのです。リクエスト・応答のヘッダは圧縮されない

リクエストヘッダのサイズは昔のように200バイトとは行かず2キロバイト以上にもなります。アプリケーションが多くのクッキーやユーザエージェントを使用するようになると、典型的なヘッダのうち700～800バイトは共通したものになります。MODEMやADSL接続の上り帯域はかなりしょぼいので、このヘッダ情報の削減はリクエスト時の遅延改善に直結するでしょう。リクエストヘッダ

おまけにいくつかのヘッダは何度も何度もリクエストの度に送信されますが、ユーザエージェントやAcceptホゲホゲなんかのヘッダ情報は基本的に変わりませんし、何度も送る必要はありません。データの圧縮転送は申告式

HTTPでは「圧縮を行ってください」と明示しないとデータは無圧縮で転送されます。コンテンツは常に圧縮されてから転送されるべきです。

以前の取り組み

HTTP高速化のためにしてきたのはSPDYの策定だけではありません。他にも、取り分けトランスポート層とセッション層レベルにおいて、高速化のためのカードがあります。 Stream Control Transmission Protocol (SCTP) トランスポート層で、ストリームの多重化や輻輳制御機能を提供する、TCPの代替となるプロトコルです。 SCTP上のHTTP SCTP上でHTTPを使おうという提案です。軽い回線ならほとんど変わりませんが、帯域が埋まるにつれてSCTP上のHTTPの方がTCP上のHTTPよりも効率がよくなるという比較実験結果があります。→ソース Structured Stream Transport (SST) 画期的な構造化されたストリームです。軽量で独立したストリームを一緒に転送できます。これはTCPやUDPに取って代わる代物です。 MUXとSMUX トランスポート層とアプリケーション層の中間層に位置するプロトコルで、ストリームの多重化を可能にします。これらはHTTP 1.1が出来る数年前に提案されたものです。

これらの提案はWEBの高速化に一役買いますが、完全ではありません。基盤となる転送プロトコルの如何によらず、HTTPに内在する圧縮・優先度などの問題は修正されるべきです。いつでもどんな人でも転送方法の変更を広めるのは大変です。が、私たちはアプリケーション層の欠点を是正すれば大きな実りがあると信じます。この方法ならインフラへの変更は極微ですし、多くのゲインが臨めますから。

目標

SPDYプロジェクトは半端なくWEBの遅延を減らすためのアプリケーション層プロトコルの定義・実装です。

SPDYの目標は―

ページ読み込み時間を半分にする。下に記した通りだが、この下ごしらえは達成済みだ。
プロトコル実装のわずらわしさを最小限に抑える。ＳＰＤＹは下層にＴＣＰを用いるので、既存のネットワークインフラに変更を加える必要がありません。
ＷＥＢサイトの作者がコンテンツを変えなくてよい。必要なのはサーバーソフトとブラウザがＳＰＤＹ転送をサポートすることである。
ＷＥＢの転送速度問題に興味がある仲間と解決する。この新しいプロトコルをオープンソースコミュニティや産業スペシャリストの皆さんと開発したいです。

技術的な目標としては―

一つのＴＣＰ接続でたくさんのＨＴＴＰリクエストを処理する。
ＨＴＴＰの要らないヘッダ情報を削除・必要なヘッダ情報を圧縮することにより、必要な帯域を減らす。
実装が容易かつ効率的なプロトコルを定義する。データの端を削除したり簡単に解釈できるメッセージ書式を定義したりして、ＨＴＴＰの煩雑さを解消したいです。
より良い安全性と既存ネットワークとの互換性のため、基礎となるトランスポート層にSSLを採用します。SSLの採用は速度低下を招きますが、将来的にはWEBはセキュアな通信だけになるものと考えています。あと、プロキシを介しての通信が切断されていないと保証するにはSSLの利用が必要です。
いつでもサーバ側からクライアント側に働きかけられるようにします。

設計・特徴

SPDYは一つのTCP接続上を複数のデータが同時に転送出来るセッション層をSSLの上に配置します。

SPDYは暗号化と回線上のデータ転送に新しいフレームフォーマットを採用しますが、HTTPのGET・ POSTメッセージの書式はそのままです。

↑上位層
アプリケーション層：HTTP
セッション層：SPDY
プレゼンテーション層：SSL
トランスポート層：TCP
↓下位層

ストリームは双方向転送対応です。サーバからでもクライアントからでも開始できます。

SPDYは普段の転送でも一歩踏み込んだ転送方法でも転送時間の短縮に成功しました。

基本的な特徴

多重転送

一チャンネル上で交互にリクエストを取り扱えるので、SPDYは一つのTCP接続上でいくらでも同時転送を可能にします。必要なコネクションは少なく済む上に、１パケットの中身が密なため、その効率たるやTCPの比ではありません。.

リクエストの優先度

並行してデータ転送ができるようにして一つ問題を解決すると他の問題が生じます。一チャンネルあたりの帯域幅を制限すると、クライアントはチャンネルが閉じちゃうんじゃないかという恐れから、リクエストをブロックしてしまいます。この問題を解決するため、SPDYはリクエストに優先度を設けました。クライアントはサーバへのリクエストそれぞれに優先順位を設定できます。これで混雑したネットワーク環境でどうでもいいリクエストのせいで優先度の高いリクエストが保留される心配を取り除けました。

HTTPヘッダの圧縮

SPDYはリクエスト・応答のHTTPヘッダを圧縮することで、転送パケットサイズを小さくします。

一歩踏み込んだ特徴

さらにSPDYには一歩進んだ特徴があります。server-initiated streamsです。これはクライアントからのリクエストなしにサーバ側からデータを転送する仕組みです。この設定は以下2種類いずれかの方法により実装できます。

HTTPヘッダによる通知

サーバがクライアントに X-Associated-Content ヘッダを出力すれば実装できます。このヘッダは「サーバはクライアントが要求しなくてもデータ転送開始できますよ」という通知です。ユーザが最初にこのサイトを訪れた時などにこれを行えば非常に良いユーザエクスペリエンスになるでしょう。

データの必要性を確認

サーバが自動的にデータを送るというより、一旦 X-Subresources ヘッダを使って「クライアントが本当にデータを求めているか」を確認してからデータを送る方法です。ただし、この方法では一旦クライアントの了解を取るまでに時間が必要になるので、低速回線では数百ミリ秒の遅れとなることもあります。が、ユーザが資源を必要としない可能性があれば良い手段ですし、そうでなくても常にクライアントから呼びかけるしかないよりはましです。

さらに詳細がしりたければ右記リンク先を参照してください SPDY draft protocol specification

実装

こんな環境を構築しちゃいました。

TCP・SSL上で動作するHTTP・SPDY応答に対応した高速なメモリ上のサーバです。近い将来オープンソースのコードとしてリリースする予定です。
TCP&SSL上で動くHTTP・SPDYに対応させたブラウザ：Google Chromeです。ソースコードは右記リンクから取得してください。ただし、そのうち変更しますがまだ名前は開発コードの flip です。 Google Chrome SPDY対応版リンク
ちゃんとページが転送されてるか確認できるテスト・ベンチマーク用のインフラです。元のサーバヘッダ・文字コード・URLなどが正しく保持されているか確認します。

予備試験結果

研究室では試作品のSPDY対応Google ChromeブラウザとWEBサーバで、SPDYとHTTPを比較したベンチマークテストを何度も行いました。

家庭のネットワーク環境を想定した１%のパケット損失がある環境で、上位100中の25サイトのダウンロードしました。それぞれのサイトで10回ずつダウンロードを行い、平均ページ読み込み時間を算出しました。結果、SSL暗号化無しのTCPで27％～60%・SSL暗号化有りで39%～55%の速度向上が測定出来ました。

結果を下記テーブルに示します。DSL回線は上り 375 [kbps], 下り 2 [Mbps]。ケーブル回線は上り 1 [Mbps], 下り 4 [Mbps]です。

	平均 [ms]	速度向上	平均 [ms]	速度向上
HTTP	3111.916		2348.188
SPDY 基本複数接続 TCP接続	2242.756	27.93%	1325.46	43.55%
SPDY 基本単体接続 TCP接続	1695.72	45.51%	933.836	60.23%
SPDY 単体接続 server push / TCP	1671.28	46.29%	950.764	59.51%
SPDY 単体接続 server hint / TCP	1608.928	48.30%	856.356	63.53%
SPDY 基本単体接続 SSL	1899.744	38.95%	1099.444	53.18%
SPDY 単体接続クライアント先読み SSL	1781.864	42.74%	1047.308	55.40%

多くの場合、SPDYは接続数によらず、全てのリクエストを一コネクションで処理出来ました。これでリクエストの並列処理が実用的レベルと分かりましたが、一部単一接続では失敗したケースがありました。これらのケースでは、SPDYはサイト毎に新しいコネクションを張る度にオーバーヘッドを受け取らねばなりませんでした。次の二種類の状況でテストをしました。

すべてのサイトを一つのTCPコネクションに集約する
すべてのサイトを尊重する（つまり一サイトにつき一コネクション）

これら二つを厳密に「一サイト」と「複数サイト」のテスト結果に盛り込みました。おそらく、現実世界の結果もこれらの間に収まるんじゃないでしょうか。

ヘッダ圧縮の影響

ヘッダの圧縮により、リクエストで最大88%・応答で最大85%のサイズを削減出来ました。上り転送速度が375Kbpsの低速DSL回線である種のサイト、例えば多くのリクエストが必要なサイトにアクセスするサイトなんかでは、特にリクエストヘッダ圧縮が速度向上に貢献します。ヘッダ圧縮のみでも 45～1142 [ms] の無駄を省けることが分かりました。

パケット損失とRTTの影響

パケット損失とRTT(Round Trip Time ＝確認応答にかかる時間)がどんな影響をもたらすか知るため、二つ目のテストを実施しました。このテストではケーブル回線しか試していませんが、パケット損失とRTTのばらつきは再現しました。

SPDYの遅延改善は、パケット損失率の増加につれて顕著になりました。2%のパケット損失率の条件下では、48%の速度向上という結果が得られました。※この速度向上率はパケット損失率2%の辺りから弱弱しくなり、2.5%以上の条件下では完全に消えました。実世界のパケット損失率は大体１～２％で、アメリカのRTTは平均50～100 [ms] です。

SPDYがパケット損失に強い理由はいくつか挙げられます。

SPDYは効率が良ければHTTPより40%パケット数を減らせます。これはパケット損失による影響が減ることを意味します。
SPDYが使うTCPコネクション数は少ないので、SYNパケット損失時の変化が軽微だと分かります。多くのTCP実装では、この遅延は不相応なくらい高くつき、３秒かかることもあります。
SPDYのより効率的となったTCPの使用は、基本的にTCPの再伝達時間を利用するよりも早い再伝達をもたらします。

200 [ms] のRTTで最大27%の速度向上。SPDYの遅延への強さはRTTの増加時でも観測できました。SPDYがRTTの増加に強いのは全部のリクエストを並行処理するからです。HTTPクライアントが一サイトに４つのコネクションを張って20ファイルを取得しようとしたらRTT５つ分待たねばなりませんが、SPDYでは１つ分で済みます。

	平均読み込み時間 [ms]	速度向上
パケット損失率	HTTP	SPDY (TCP)
0%	1152	1016	11.81%
0.5%	1638	1105	32.54%
1%	2060	1200	41.75%
1.5%	2372	1394	41.23%
2%	2904	1537	47.7%
2.5%	3028	1707	43.63%

	平均読み込み時間 [ms]	速度向上
RTT [ms]	HTTP	SPDY 通常TCP
20	1240	1087	12.34%
40	1571	1279	18.59%
60	1909	1526	20.06%
80	2268	1727	23.85%
120	2927	2240	23.47%
160	3650	2772	24.05%
200	4498	3293	26.79%

今後

最初の実験結果でSPDYが有望なのがわかりましたが、実際の世界で使ったらどうなるかはまだわかりませんし、SPDYには改善の余地があります。特に。帯域の使用効率はまだ悪いダイヤルアップ帯域の効率は90%近くまで高まりましたが、高速回線の効率はまだ32%以下です。 SSLの採用がもたらす遅延・展開の問題

次の3点が問題となるので、まだSSLにはさらに改良が必要です。

SSLのハンドシェイクでさらにRTT(Round Trip Time ＝確認応答にかかる時間)が増える。
暗号化が必要である。
一部プロキシではキャッシュが困難である。

パケット喪失時のテスト結果は完全じゃない精力的にパケット喪失の調査を行っているが、現実でのWEBパケット喪失に至るモデルを十分に構築できていない。 SPDYの一コネクション再構築には複数コネクションでの通信より時間がかかる RTTがとても高い時、未だに一コネクションの利用よりも複数コネクションの利用に軍配があがる。まだ、どのタイミングでSPDYがコネクションを生成・閉塞すれば効率が良いか見極める必要がある。サーバにはさらなる英知を詰め込める。まだ server initiated streams やクライアントネットワーク情報を調査する必要がある。

これらの挑戦を手伝っていただけるならあなたも参加できます。:

フィードバック・コメント・提案・アイデア出しはこちらへ→chromium-discuss discussion group
ダウンロード・実行・テストはこちらへ→Google Chrome client code
コードの基礎改良に寄与する

FAQ

すでにパイプライン化がHTTPの転送速度問題を解決したんじゃないの？

いいえ、解決されていません。確かに一つのTCPコネクションで複数のリクエストを処理出来るようにはなりましたが、まだ一つのストリームでしかないのです。一つサイズの大きなリクエストやパケットロスが存在すると、ストリーム全体の遅延に繋がります。メジャーなブラウザはこの機能を無効にしていますので、パイプライン化を広めづらいのは明白です。

SPDYはHTTPの代替なの？

いいえ、代替ではありません。HTTPの一部分を成すことにはなりますが、概ねそのままで、アプリケーション層の最上位では全く同じです。SPDYはHTTPのメソッド・ヘッダ・その他の成分を用います。ただ、SPDYはコネクション管理やデータ転送形式など、プロトコルの一部を改良するだけなのです。

名前の由来は何？

速度（SPEED）を言い得た命名を望んでました。圧縮（無駄を省略すること）が転送速度を改善するというところと、読みがスピーディだというところから決めました。

SPDYを使うにはトランスポート層の変更も必要なの？

トランスポート層プロトコルの切り替えが高速化に有意かどうか判別するにはもっと調査が必要です。トランスポート層のプロトコル切り替えにはただならぬ複雑な努力が必要ですが、TCPとHTTPをアプリケーション層で変更できれば、今より楽になると思います。

TCPは輻輳とネットワーク衝突を回避するよう十分テストされてますが、SPDYがインターネットを壊しちゃうってことは？

いいえ、心配御無用です。SPDYはTCPと互換性があるので、TCPの輻輳制御アルゴリズムの恩恵に肖れます。さらにいえば、HTTPはすでにインターネットの輻輳制御方法を捻じ曲げちゃっています。例えば、最近のブラウザは一つのWEBサーバに対して６つのコネクションを生成してますし、WEBサーバ側も最初のデータ格納サイズを4パケット分に増加させてます。TCPコネクションそれぞれが独立だから、最初は 6 * 4 = 24 パケットを転送することになるわけです。これでは初動が遅くなってしまうので、SPDYでは対照的に一つのコネクションのみで実装することにしたわけです。

SCTPって何？

SCTPは面白いトランスポート層の代替プロトコルです。一コネクションで複数のストリームを転送できるようになる訳ですが、悲しいことに使いたければ家のルータを変更するなど転送スタックへの変更が必要になります。また、SCTPだけじゃ銀の弾丸にはなりません。効率よく使うには、サーバ・クライアント間でアプリケーション層の変更もまた必要になるのです。

BEEPって何？

BEEPは福袋のような特徴を持つ面白いプロトコルで、ページ読み込み高速化に的を絞って設計されたわけじゃありません。バイナリではなくてテキストをベースにしたプロトコルでいろんな拡張ができますが、ちょこっとセキュリティに問題があり、正確に転送するのは難しいです。

MySQL5.5で準同期レプリケーション構築

MySQL5.5を用いた通常・準同期レプリケーション構築の解説です。レプリケーションとは何か、通常・準同期レプリケーションの対比、構築方法、必要な保守作業など。対象読者は多少MySQLサーバの設定を行ったことのある方を想定しています。

基礎知識

レプリケーションを構成する要素・どんな動作をするか・レプリケーションの種類。レプリケーション構築の前に知っておくべきことを解説します。

レプリケーションとは何か

MySQLのレプリケーションはマスターサーバのデータを一つ以上のスレーブサーバに複製することでデータを冗長化する機能です。

レプリケーションを用いれば複数個所にデータベースの複製を設置できるので、荷分散と共に可用性・信頼性を向上させられます。設定は容易で、どのサーバからもSELECT文でデータを参照できます。しかし、更新クエリはマスターサーバにしか行えません。つまり、レプリケーションで書き込みのスケールアウトは出来ません。更新クエリの負荷を分散させる必要が無い場合にはレプリケーションをお勧めします。更新クエリの負荷分散が必要な場合は、クラスタリング設定を行うか、別のソフトウェアを試してください。

通常レプリケーション・準同期レプリケーションの違い

通常レプリケーションの動作

通常レプリケーション特筆すべき点は、マスターサーバはログを出力するだけで自己完結していることです。スレーブサーバの片思い的な動作方式です。

役割に応じた動作｜通常レプリケーション

マスターサーバの役割は単純で、更新クエリ実行時にバイナリログを出力するだけです。

スレーブサーバは下記の通り多少がんばります。

レプリケーション権限を持つユーザでマスターサーバにログイン
今までコミットしたバイナリログからさらに更新があるか確認
更新があればその部分のバイナリログを取得し実行
マスターサーバからログアウト

スレーブサーバはバイナリログ実行後すぐにログアウトするわけではなく、実際は２～３の動作を繰り返します。

コミット時の動作｜通常レプリケーション

実際に更新クエリをコミットした時の振る舞いを見ましょう。

マスターで更新クエリ実行時にバイナリログに記録
スレーブがバイナリログが更新されたことに気付いたら、マスターからスレーブへバイナリログを転送
スレーブで更新クエリを実行

手順「２．」の転送が完了する前にマスターがクラッシュした場合、齟齬が生じ「コミットしたのにデータが巻き戻されてる」という事態に陥る可能性があります。

準同期レプリケーションの動作

準同期レプリケーションのシステム構成要素は通常のレプリケーションと共通。PostgreSQLで言う同期レプリケーションと同じ仕組みです。準同期レプリケーションではマスターはスレーブの面倒を見ます。毎朝登校時間に起こしに来てくれる幼馴染型の動作をします。

役割に応じた動作｜準同期レプリケーション

マスターサーバの役割は通常レプリケーションよりも増えます。

クライアントから更新クエリを受け取って、バイナリログをスレーブに転送する
バイナリログを受け取ったスレーブは「受け取りました」サインをマスターに返信してからコミット

スレーブサーバは気楽です。

レプリケーション権限を持つユーザでマスターサーバにログイン
マスターからバイナリログを送られたら「受け取りました」サインをマスターに返信してからコミット
マスターサーバからログアウト

スレーブサーバはバイナリログ実行後すぐにログアウトするわけではなく、実際は２の動作を繰り返します。

一定時間（設定で変更可能）待機してスレーブからの応答が無い場合、マスターはスレーブを無視してバイナリログをコミットします。

コミット時の動作｜準同期レプリケーション

実際に準同期レプリケーションを構築したMySQLサーバで更新クエリをコミットした時の振る舞いを見ましょう。

MASTER側からSLAVE側にSQLバイナリログを転送
SLAVE側からMASTER側に「更新出来ますよ」サインを返信
MASTER側・SLAVE側それぞれで更新クエリを実行

この動作手順では、最初にSQLバイナリログを送信しているため、MASTERとSLAVE間で齟齬が生じる可能性は非常に低いです。

冗長化方法の対比

通常レプリケーションの動作と準同期レプリケーションの動作で見てきたように、構成する要素は同じで動作の違いは小さいです。が、それぞれ癖がありますので、どちらを選択するかは吟味しておくべきです。

両者の対比を紹介しますが、データの完全性を求めるなら準同期レプリケーション。数分の更新遅延を気にしないなら通常レプリケーションが私の結論です。

応答速度

準同期レプリケーションはクエリ実行時にバイナリログをスレーブに送って応答を待つため、通常のレプリケーションよりコミットまでの応答時間が長くなります。

コミットデータの完全性

通常レプリケーションで、マスターが更新したバイナリログを取得する前にマスターが落ちると、「コミットしたのに巻き戻ってる…」という自体に陥る可能性があります。また、マスターがコミットしてからスレーブがコミットするまでの間にスレーブのデータを参照すると、古いデータを読み込むことになります。つまり、通常レプリケーションは完全性に難があるわけです。金銭を取り扱うようなシステムでは通常のレプリケーションを控えねばなりません。

保守性

保守は通常レプリケーションの方が楽です。マスターはスレーブと完全に独立して動作していますし、スレーブを落としてもマスターの動作が遅くなることはありません（準同期では一定時間スレーブの応答を待機する）。そして、多少設定が楽です。

レプリケーションの構築

複数のレプリケーションを構築する場合も手順は同じなので、『一台のマスター・一台のスレーブ』を構築します。

「同じ方法で再構築出来る」をモットーに構築します。
通常のレプリケーションも準同期レプリケーションも構築方法はほとんど同じです。異なる点では適宜記述します。
この構築例のOSはマスター・スレーブ共にSSH, MySQL-Serverインストール済みのCentOSを想定していますが、他の構成でも流用できます。

手順

構成の設計とMySQLサーバ設定の確認
マスターのレプリケーション設定・データベースのコピー
マスターのバックアップデータをスレーブに転送
スレーブのレプリケーション設定
動作確認

構成の設計とMySQLサーバ設定の確認

下記の構成でレプリケーション構成を行います。分かる変数を各自の環境に合わせたら次に進みましょう。

コンソール操作

SSHなどを用いて実際にサーバ機を操作します。

マスターサーバの操作

マスターの MySQLサーバーが使用するポートを解放

レプリケーションを行うには、マスター側のMySQLサーバの使用するポートが外部に公開されている必要があります。MASTERでファイアーウォールを利用している場合、TCP 3306 番ポートを開放して下さい。また、アウトバウンドのサーバとレプリケーションを行う場合は、ルータのネットワークアドレス変換を設定してください。

マスターにレプリケーション用ユーザーを作成

まず、レプリケーション権限のみを持ったレプリケーション専用のユーザーを作成します。MASTERのMySQLコンソールで以下のSQLを実行します。

GRANT REPLICATION SLAVE ON *.* TO replication_user@'slave.example.com' IDENTIFIED BY 'password';

ユーザ作成に成功したら、設定を反映してください。

FLUSH PRIVILEGES;

マスターのレプリケーション設定とデータベースの複製

レプリケーション構築の勘所で、すべきことは下記2点です。

マスター用の設定を行う
スレーブ側にマスターのデータを転送するため現在状況を複製する

「１．」では設定読み込みのためにMySQLサーバを再起動する必要がありますし、「２．」ではデータコピー中にユーザがデータベースに書き込めなくする必要があります（バックアップ中にデータを更新されては困る）。途中で手を止めるとサーバ停止時間が伸びてしまうので、ひと通り手順をさらってから作業に進んでください。マスター用の設定を行う

「マスター用の設定」とは、下記三点のことを指します。すでに設定済みの場合はスキップしてOKです。

SQL実行時にクエリのバイナリログを出力する
どのサーバか識別するためサーバIDを付与する
準同期レプリケーションを行う場合に準同期レプリケーションマスター用のモジュールを読む

これらの変更はvi /etc/my.cnf で [mysqld] 中に下記を追加して行います。

server-id=20 # サーバー固有のIDを指定します
rpl_semi_sync_master_enabled=1 # 準同期レプリケーションのみ追加 準同期レプリケーションマスター動作を有効にします
rpl_semi_sync_master_timeout=1500 # 準同期レプリケーションのみ追加 更新時、SLAVEが応答しない時のタイムアウト時間を1.5秒に設定します
log-bin # バイナリログを生成するようにします
expire_logs_days = 14 # ログの保持を保証する期間（日数）です。０以外の値にすると、ログローテーション・サーバ再起動のタイミングで指定日数以上経過したログファイルは自動的に削除されます。

編集したら /etc/rc.d/mysqld restart でマスターを再起動し、設定を反映してください。スレーブ側にマスターのデータを転送するため現在状況を複製する

下記役割を持つ、A,・B ２つのターミナルを用意します。

A：マスターのMySQLコンソール上でSQLクエリ実行する
B：マスターのシェルの操作を行う

～ここからノンストップ作業～

ターミナルAで下記SQLを実行し、 MySQLサーバの書き込みを禁止します。※ログアウトするとロックが解けてしまうため、コピーが完了までAはMySQLサーバからログアウトしてはいけません。

FLUSH TABLES WITH READ LOCK;

下記SQLを実行し、現在のログ位置を取得します。FileとPositionの値をメモしておいてください。→上のフォームにメモってくる

SHOW MASTER STATUS;

mysql> SHOW MASTER STATUS;

File	Position	Binlog_…
mysqld-bin.000001	805

1 row in set (0.00 sec)

スレーブ側にデータを転送する前に圧縮します（データサイズや回線速度によっては圧縮せずに cp を使った方が速く終わる場合もあります。要はマスターのDBデータをスレーブにコピー出来れば良いので、適宜方法を選択してください）。

cd /var/lib/mysql
tar zcvf master-mysql-data.tar.gz *

ターミナルAで下記クエリを実行してロックを解除してください。

UNLOCK TABLES;

～ここまでノンストップ作業～

マスター→スレーブデータ転送

前項で作成したマスターデータベースの複製をスレーブに転送します。転送方法はSFTPでもFTPSでもSCPでもUSBメモリでもフロッピーディスクでも構いません。

下の例ではマスター側のコンソールでSFTPを使って転送します。

cd /var/lib/mysql
sftp -oPort=22 replication_user@slave.example.com
replication_user@slave.example.com’s password: # パスワード応答
cd /var/lib/mysql
put master-mysql-data.tar.gz

スレーブサーバの操作

スレーブ設定ファイル

スレーブとして動作するように設定ファイルを編集します。

vi /etc/my.cnf で [mysqld] 中に下記を追加してください。

server_id=20 # サーバー固有のIDを20に設定します
plugin-load=rpl_semi_sync_slave=semisync_slave.so # 準同期レプリケーションのみ追加 準同期レプリケーションスレーブ動作を有効にします

※旧ヴァージョンのMySQLサーバでレプリケーションを行っていた方へ…MySQLのヴァージョン５．５未満のレプリケーションで使用していた master_host, master_port, master_user, master_password の設定項目は、my.confに記述できなくなりました。これら変数を my.cnf に記述してMySQLサーバーを起動しようとすると、 /var/log/mysqld.log には [ERROR] /usr/libexec/mysqld: unknown variable ‘master_host=master.example.com’ とエラーメッセージが出力され、起動ができません。これらの変数はSLAVEで CHANGE MASTER TO ... クエリを実行した時に自動的に /var/lib/mysql/master.info に書き込まれるようになりました。

編集したら /etc/rc.d/mysqld restart でSLAVEを再起動し、設定を反映してください。

マスターを指定

スレーブサーバに「どのMySQLサーバをマスターとするのか」の情報を与える必要があります。スレーブのMySQLコンソールで下記SQLを実行してください。

CHANGE MASTER TO master_host='master.example.com', master_port=3306, master_user='20', master_password='password', master_log_file='mysqld-bin.000001', master_log_pos=805;

実行後 /var/lib/mysql/master.info が生成されるのが確認できます。

マスターと同期開始

スレーブのMySQLコンソールで下記SQLを実行してください。

START SLAVE;

動作テスト

スレーブの状態を確認する

SLAVE側のMySQLコンソールで下記クエリを実行し、レプリケーションが構築できているか確認してください。エラー無くマスターと同じ位置までログが進んでいれば正常です。

SHOW SLAVE STAUS;

PCの再起動

スレーブサーバのPC再起動です。PCを再起動してもスレーブ状態は維持されます。レプリケーションの再設定（START SLAVE）が不要なのが分かりました。

マスターでコミット

マスターでの更新クエリ実行です。マスターにテーブルを作って、SLAVE側で反映されるかを確認してください。

CREATE DATABASE hoge;

SLAVE側でも同じ更新が行われるはずです。

スレーブでコミット

※レプリケーションが壊れる可能性があるので本番環境でこのテストを行わないでください。

スレーブ側で更新クエリを実行するとどうなるか。スレーブ側でも更新クエリは実行できてしまいます。マスターとデータの齟齬が生まれてしまうので、SLAVE側での更新は行わないようにしてください。スレーブ側でデータベースを更新出来なくするのもひとつの手ですが一長一短です。スレーブ側で更新できるなら、マスターが不慮に停止しても迅速にサービス復旧できるからです。

スレーブダウン時のコミット

準同期レプリケーション構築時、スレーブがダウンしている場合の動作です。スレーブのMySQLサーバーをストップしてからマスターで更新クエリを実行すると、 rpl_semi_sync_master_timeout で指定した時間 [ms] 待機してから更新クエリが実行されます。このクエリ実行後にスレーブのMySQLサーバーを立ち上げると同じ更新が行われました。スレーブがダウンしても expire_logs_days で示した日数以内に再起動出来れば問題ないようです。

メンテナンス

レプリケーション構築後にどんなメンテナンスが必要かと言っても場合によりけりなのですが。個人的にチェックすべきと思った点を抑えます。

障害発生時

スレーブサーバが死んだ時はほぼ問題無しです。準同期レプリケーションであれば更新クエリ実行時に rpl_semi_sync_master_timeout で指定した時間待機するので多少パフォーマンスが低下しますが、これまでの手順どおりに再度レプリケーションを組み直せば良いだけです。

問題はマスターサーバが死んだ場合です。フェイルオーバーが必要になります。マスターサーバが息をしていない場合はスレーブサーバで下記クエリを実行してください。

RESET MASTER;

これでスレーブはマスターに昇格し、元マスタのバイナリログを読みに行かなくなります。なお、既存のバイナリログ関係ファイルはすべてリセットされます。

バイナリログのサイズ

データベースの更新頻度が低ければ2週間のバイナリログ自動削除で大丈夫ですが、更新頻度が高くなるとものすごい勢いでバイナリログが書き込まれることになります。「ハードディスクの中がログファイルでパンパンだぜ」という事態に陥る可能性があるわけです。時折ハードディスクの残量とバイナリログの増加速度を見てバイナリログの保持期間を調整してください。

バックアップ

レプリケーションを組むだけで安心してはいけません。RAIDを組んでもバックアップは別途必要と言われるように、レプリケーションを組んでもDBのバックアップは別途取得するようにしてください。

貴方の中の全どぢっ娘がうっかりデータ全削除をしてしまう可能性はゼロではないからです。

その他

後書き

MySQL5.5で準同期レプリケーションをしようとした時に、頭から尻尾まで解説したサイトが見つかりませんでした。大抵、通常のレプリケーションを組んであるのが前提だったり、細部がはしょってあったり。それで、MySQL5.5を用いた準同期レプリケーション設定の解説をしようと思いました。

しかしながら、なかなかうまくいかないもので。作ってから「僕の解説中途半端だお…」と気づきました。気付いたもののなかなか更新出来ず、半端な解説を掲載したまま一年近くが経過してしまいました。

数日ああでもないこうでもないと考えて作成したMySQL5.5+準同期レプリケーション構築の解説ドキュメント。多少なり役立てたのであれば幸いです。

リンク

とみんのブログ – 今更ながらMySQLのレプリケーションその1 準同期レプリケーションについての解説しています。

現場指向のレプリケーション詳説運用しながらのレプリケーションの構築方法を解説しています。

半袖野郎 blog.hansode.org – 2009年05月08日 master.infoの構造・作り方を解説しています。

OpenGroove – レプリケーション時のRESET MASTERとRESET SLAVE レプリケーション時のRESET MASTER・RESET SLAVEコマンドの動作を解説しています。

Hyper-V Server 2008 R2 SP1 の仮想化環境構築

Hyper-V Server 2008 R2 SP1 を用いた仮想化環境構築を解説します。

はじめに

想定読者

下記スキルを持つ方を想定して解説しました。

　１．Windows 上のコマンドプロンプトで簡単な操作が出来る
　２．CDからOSをbootしてWindows 系OSをインストールしたことがある
　３．Windows 系OSのネットワーク共有機能を使ってファイルを移動したことがある

この辺の経験があれば可能な設定です。
逆に、これら単語・操作が不明な方には難しいです。

構築のコンセプトとゴール

『Windows Vista以上のOSが搭載されたクライアントPCを持つ人が、サーバーPCにHyper-V Server 2008 R2 SP1をインストール・設定。もう変なことをしなければエラーは出ない・スムーズにシステム構築を楽しめる状態』がゴールです。

コンセプトは

　・安上がり
　・漏れ無し
　・転んでも泣かない

です。出来るか不明ですが。

動作確認に使用したハードウェア

下記は私がHyper-V Server 2008 R2 SP1の動作確認に使用したハードウェアです。

　CPU： Intel Core i7 2600
　マザーボード： ASUS P8H67-M EVO Rev.3
　メモリ： DDR3 8GBx2 = 16GB
　電源：玄人志向　KRPWSS500W85+
　HDD： Western Digital 500GB + 2TB
　SSD： ADATA 120GB
　光学ドライブ：安い奴

クライアント側は適当にVistaか７機を選べば簡単に動くはずなので割愛します( ´ρ｀)

どんなものか

三行で説明

Hyper-V Server 2008 R2 SP1 は無料のハイパーバイザ型の仮想化OSです。
買ったPCに Hyper-V Server 2008 R2 SP1 をインストールすると、その上に Windows 7 や Windows XP、CentOS や ubuntu などたくさんのOSをインストール・起動させて、それぞれリモートから操作出来るようになります（ただし、クライアントOSがライセンス違反にならないか確認する必要があります）。
VMware ESXiのマイクロソフト版と考えても良いですし、Windows Server 2008 R2 のHyper-V機能部分だけを切り出した物と考えても構いません。

メリット

数ある仮想化ソリューションの中、 Hyper-V Server 2008 R2 SP1 を選ぶメリットはいくつか挙げられます。

ハードウェアに困らない

同じハイパーバイザ型の仮想化OS：VMware ESXi と比較して、ハードウェアに困らないのがHyper-V Server R2 SP1 の大きなアドバンテージです。

VMware ESXi を使用するには、VMware ESXiをインストール可能なハードウェアを調べて、それを購入してインストールしなければなりません。
ハードウェアを選ぶわけですね。

それに比べてHyper-V Server 2008 R2 SP1 のベースはWindows Server 2008 R2。
Windows Server 2008 R2のベースはWindows 7です。
Windows 7のドライバがそのまま使えるため、Windows 機が動作するPCであれば高確率で利用可能なわけです。

無駄なリソースが少なくて済む

Hyper-V Server 2008 R2 SP1 には仮想化に必要な機能と操作に必要な一部機能しかありません。
そのため、使用リソースが少なく、高いゲストOSのパフォーマンスが期待できます。

Microsoft製である

信頼と安心のMicrosoft製品。
既存 Windows系OSのリモート操作と同じ感覚でインストール・利用が出来ますし、他Microsoft製品のように今後長くHyper-V Server がサポートされると見込めます。

デメリット

ゼロとはいかないデメリット。

ハードディスク or SSDが必須

VMware ESXi はUSBメモリからBOOT可能ですが、Hyper-V Server 2008 R2 SP1 を利用するためにはハードディスク（またはSSD）が必要になります。

導入の敷居が高い

個人で仮想化をしたくなったらVMware PlayerやOracle VM VirtualBoxなどを利用するのが一般的ですよね。
これらの環境構築は簡単ですが、Hyper-V Server 2008 R2 SP1の環境構築にはある程度の知識・スキル・設定が要求されるため、導入の敷居が高いです。

利用者が少ない

導入の敷居が高いという話の延長になりますが、利用者が少ないです。
もしかしたら企業や何かで利用されている方はいるかもしれませんが、少なくとも個人で使用されている方は多く無いでしょう。
なので、「よし、村瀬の家に遊びに行ってこの仮想イメージ動かすぜ！」と意気込んでも、村瀬に「ごめん、うち、Hyper-Vのイメージ動かせないんだ」と言われてしまう可能性が高いです。

一応、別の仮想イメージ形式への変換ツールが出回っているには出回っていますが、完全動作する保証はありませんし、出来たとしても時間がかかるため即座に利用出来ないと考えた方が良いです。

ドキュメントが少ない

Microsoft社のサイトに機能説明のドキュメントが充実しています。
が、Microsoft独自の用語や機能がある・英語を和訳してあるため、苦無く英文を読めるスーパーハカー以外には分かりづらいと思います。また、目的別の解説はありません。

さらに、個人利用者が少ないため、『適当に備忘録書いてる人のブログ見て設定すりゃいいや』が通じ辛いです。
検索にヒットする数が少ない上に、不備があったり環境によって必要な設定が違っていたりするためです。

インストール

イメージファイルを取得

# 参考URL
# http://technet.microsoft.com/ja-jp/evalcenter/dd776191.aspx

参考URLのウィザードに従ってISOイメージを取得し、DVD-Rなどのメディアに書きこんでください。

boot

光学ドライブからBOOTするようBIOS設定を変更し、PCの電源をONにしてください。
Hyper-V Server 2008 R2 SP1のインストーラーが起動します。

ウィザードに従いインストール

インストール時の操作・手順は Windows 系 OSをインストールする時とほぼ同じ（というかさらにシンプル）です。
インストール先のドライブを選択し進むとインストールが完了します。

管理者パスワードを入力

インストールが完了すると、Hyper-V Server 2008 R2 SP1が立ち上がります。
最初に管理者（Administrator）のパスワード入力を求められるので入力します。

ドライバインストール

管理者パスワード入力後、「アクティブなネットワークアダプターは見つかりませんでした。」と警告が出るかもしれません。
これは恐らくNIC（LANカード）のドライバがインストールされていないためです。

ドライバのインストール方法には二種類あります。
１．インストーラーを実行
２．コマンドラインからインストール用のコマンドを実行

インストーラーを実行

Windows 7 でドライバをインストールする時のように、インストーラーを直接実行出来ちゃう場合があります。

例えば下記コマンドを実行すればウィザードが起動され、P8H67-M EVO Rev.3 のインストーラーディスクからNIC用ドライバをインストールできました。
E:\>Drivers\LAN\Windows7\setup.exe

同様にAudio
E:\>Drivers\Audio\Driver\Setup.exe

同様にBrowser Configuration Utility
E:\>Drivers\BCU\ASUSEGBCU00_v1.0.10.0_20091026.exe

このように実行ファイルを使って、インストールに失敗した項目は次の方法をためすのが良いと思います。

コマンドラインからインストール用のコマンドを実行

# ドライバインストール参考URL
# http://cloud.watch.impress.co.jp/epw/cda/2008lab/2008/10/17/14078.html

Hyper-V Server 2008 R2 SP1 はすべてのexeファイルを実行出来るわけではありません。
「Windows 7用だからこのOSには使えないよ」と言われたり、Hyper-V Server 2008 R2 SP1 が実行に必要なランタイムを持っていなかったりするためです。
この場合は下記コマンドにより直接ドライバ： *.inf ファイルをインストール出来ます。

　PNPUTIL -i -a filename.inf

フォルダ内の複数ドライバを一気にインストールしたい場合は下記のようにワイルドカードを使ってインストール可能です。

　PNPUTIL -i -a *.inf

ちなみに、対応していないドライバをインストールしようとしたらエラーで止まりますし、複数回同じドライバをインストールしようとしても「もうすでにありますよ」と止められます。
使えないドライバがインストールされたり重複してインストールされたりはありませんので、気楽に試行して良いと思います。

サーバー操作

サーバー上では馴染みのGUIが利用出来ません。
サーバー上の操作で必要な知識を解説します。

ウィンドウ

ログイン後、表示されるのは黒と青2つのウィンドウです。

　黒いウィンドウ…コマンドプロンプト。 cmd で表示される

基本的な操作

# ウィンドウをすべて綴じてしまった場合参考URL
# http://social.technet.microsoft.com/Forums/ja-JP/windowsserver2008r2ja/thread/6c12fed1-7e81-434a-8537-273a2a76f5ef

ログイン後、黒と青2つのウィンドウが表示されます。

　サーバー上で操作している場合 → Ctrl + Alt + Delete
　クライアントからリモートデスクトップ接続で操作している場合 → Ctrl + Alt + End
でタスクマネージャーを起動し、『ファイル』タブ→『新しいタスクの実行』と辿ります。
　cmd と入力すれば黒いコマンドプロンプトウィンドウが生成され、sconfig と入力すれば青い設定ウィンドウが生成されます。

リモート接続

リモートデスクトップの接続を確立します。基本は sconfig を上から順番に見ていけばOKです。

ネットワーク設定

ドメイン・ワークグループの設定

sconfig 中で１．ドメイン/ワークグループを選択し、ウィザードに従えばOKです。

『ドメイン』というのは『マイクロソフト社製のアカウント・権限管理システム』と考えて構いません。
Windows Server hogehoge のサービス Active Directory を使わない限り必要ないので、分からない場合はワークグループを選択すればOKです。
ただし、すでにActive Directoryを使っているという方は権限管理が楽なのでドメインに参加した方が良いと思います。

IPアドレスの設定

sconfig 中で８．ネットワーク設定を選択してください。
すると、利用可能なNICのリストが表示されます。
設定を変更したいNICのインデックス番号を入力し、好きな設定に変更してください。

サーバーという都合上、DHCP無効で使用するのがおすすめです。

コンピューター名を変更

sconfig 中で２．コンピューター名を選択するとコンピューター名を変更出来ます。
リモートデスクトップ接続に直接必要な設定ではありませんが、クライアントサーバーからサーバーのネットワーク共有にアクセスする時に分かりやすいコンピューター名を付けておいたほうが良いと思います。

リモートデスクトップを有効化

sconfig 中で７．リモートデスクトップを選択すると、リモートデスクトップを有効にできます。
この時、
　１．高セキュリティ
　２．低セキュリティ
を選択出来ますが、「２．」は古いOSを使っていなければ必要ありません。
Windows Vista 以上であれば基本的に「１．高セキュリティ」を選択して良いようです。

実際に繋いでみる

ここで、実際にクライアントPCからリモートデスクトップ接続をテストしてみてください。
クライアントPCでリモートデスクトップ接続を選択し、サーバーPCのIPアドレス→管理者名（Administrator）→管理者パスワードを入力して接続出来ればリモートデスクトップ接続成功です。

Hyper-V コンパネ

Hyper-Vコンパネをリモートから操作出来るようにします。Hyper-Vをリモートから使用するために必要な要素は大別して下記２点です。

　１．ローカル側でリモート接続に必要なソフトウェアをインストール＆設定
　２．

ローカル側

サーバーマネージャーインストール実行

# http://watawatablog.blogspot.jp/2010/05/windows-7-hyper-v.html
# http://network.station.ez-net.jp/client/remote/hyper-v/win7.asp
# http://www.microsoft.com/ja-jp/download/details.aspx?id=7887

ファイアーウォール設定

hvremote /mmc:enable
hvremote /AnonDCOM:grant

サーバー側操作

リモート制御用のアカウント管理

パスワードの複雑さ制限を解除

# パスワードポリシーの変更参考URL
# http://ameblo.jp/k-freedom7/entry-10769753063.html
# http://blog.livedoor.jp/seec/archives/715125.html
ドメインを利用する場合は分かりませんが、ワークグループ運用する場合はサーバーとクライアントで同一のID-パスワードが必要になります。
クライアントのID-パスワードに合わせたい時があるかもしれませんが、デフォルトではHyper-V Server 2008 R2 SP1は『複雑さの要件を満たす必要があるパスワード』というパスワードポリシーが設定してあり、『小文字だけのパスワード』や『短いパスワード』などの簡易パスワードを利用出来ません。

この制限を解除する手順です。
※ただし、言うまでもなくセキュリティは低くなります。

A．パスワードポリシーをエクスポート

　下記コマンドをコマンドラインで実行すると、 secedit.cfg にセキュリティポリシーが出力されます。
　secedit /export /cfg secedit.cfg /log secedit.log /areas SECURITYPOLICY

B．メモ帳でエクスポートしたセキュリティポリシーファイルを編集する

　下記コマンドラインで、「１」で出力したセキュリティポリシーファイルを開きます。
　notepad secedit.cfg

　この中で下行を検索し、 1 → 0 に編集＆保存してください。
　PasswordComplexity = 1

C．編集したセキュリティポリシーファイルをインポート

　下記コマンドラインで「２」で編集したファイルを反映します。
　secedit /configure /db secedit.sdb /cfg secedit.cfg /log secedit.log

ユーザーを作成する

sconfig 中で３．ローカル管理者の追加を選択するとローカル管理者を追加できます。
名前・パスワードを入力すればユーザーが生成されます。

※ネットワーク回線の調子が悪い時にユーザーを作成したら、変なパスワードになってしまいました。念のため下記コマンドで明示的にパスワードを再設定した方が良いかもしれません。

net user user_name new_password

リモート管理有効化

sconfig 中で４．リモート管理の構成を選択すると、

　１．MMC リモート管理の許可
　２．Windows PowerShellの有効化
　３．サーバーマネージャーのリモート管理を許可
　４．Windowsファイアウォール設定の表示

が出来ます。

MMC（Microsoft Management Console）リモート管理というのは、リモート管理共通フレームワークです。「外部からHyper-Vを使うには必要なんだ」くらいに思って許可すれば良いと思います。

# MMC 参考URL
# http://www.atmarkit.co.jp/fwin2k/operation/mmccons/mmccons_01.html

Windows PowerShell というのは最近Microsoft社ががんばっているスクリプト言語で、Hyper-V のリモート制御も出来ます。リモート管理する時、内部的にWindows PowerShell を利用しているようなので有効化が必要です。

サーバーマネージャーのリモート管理は本命です。
これを許可すれば外部からアクセスする機能の有効化は完了します。

Windows ファイアウォール設定の表示を行えば現状が簡単に把握出来ます。

アクセス制御

ここまででリモート接続用の機能追加は完了しました。
が、ワークグループ運用する場合、この段階ではファイアウォールが邪魔をして接続に失敗します。

接続するためには下記選択肢があります
　１．ファイアーウォールを無効にする（楽＆低セキュリティ）
　２．FW設定を行う（手間＆高セキュリティ）
　３．ドメイン運用でアカウントの権限を修正する（(Active Directoryを用いるため楽＆高セキュリティただし有料。割愛）

ファイアーウォールを無効にする

Windows ファイアウォールを無効にしたい場合は下記コマンドで実現出来ます。

netsh advfirewall set currentprofile state off
※当然セキュリティは低くなります。

FW設定を行う

安全な接続元コンピューター設定

信用出来るPCからしか接続出来ないようになっています。
コマンドプロンプト上で下記コマンドを実行すると、CLIENTPC というコンピューター名を持つPCからのアクセスが信用されます。

winrm set winrm/config/client @{TrustedHosts=”CLIENTPC”}

アカウントの許可

hvremote.wsf ファイルの取得

http://archive.msdn.microsoft.com/HVRemote/Release/ProjectReleases.aspx?ReleaseId=3084
上記URLより HVRemote.wsf をダウンロードしてください。 hvremote.wsf ファイルの設置

# ネットワーク共有参考URL
# http://itpro.nikkeibp.co.jp/article/COLUMN/20060929/249460/

サーバーに直接ファイルを送ることは出来ません。
サーバーのフォルダをネットワーク共有し、クライアントから hvremote.wsf ファイルをコピーする方法をとります。

下記２コマンドで Administrator ユーザーが C:\share フォルダを hvserver フォルダとしてアクセスできるようにします。

mkdir C:\share
net share hvserver=C:\share /GRANT:Administrator,FULL

これでリモート側で \\servername\ を参照すれば hvserver フォルダへアクセスできるようになります。クライアント側からサーバー側へ hvremote.wsf をコピーしてください。

なお、ネットワーク共有を削除したい場合は下記のようにします。

net share hvserver /delete hvremote.wsf の実行

hvremote.wsf のあるフォルダに移動して、設定を行います。
なお、当ドキュメントではHyper-V をリモートから使用するユーザー名を hvclient として設定します。

# hvremote.wsf のあるフォルダへ移動
cd C:\share

# ユーザーhvclientをHyper-V利用者と設定する
# (ワークグループの場合)
cscript hvremote.wsf /add:hvclient
# (ドメイン利用の場合)
cscript hvremote.wsf /add:domainname\hvclient

リモート管理用のFW操作

下二つのコマンドにより、リモート操作時に操作拒否されないようにしてください。

netsh advfirewall firewall set rule group=”Hyper-V” new enable=yes
netsh advfirewall firewall set rule group=”ファイルとプリンターの共有” new enable=yes

# リモートボリューム管理
net start vds
sc config vds start= auto
netsh advfirewall firewall set rule group=”リモートボリューム管理” new enable=yes

Linux 利用者への注意点

http://network.station.ez-net.jp/os/linux/hyper-v/ntpd/centos/5.4.asp　に書かれている通りですが、Hyper-V 上でLinuxを動かそうとすると高確率で時間がずれます。

カーネルをロードする時、divider=10 を引数に付けるようにしてください。

月別アーカイブ: 6月 2020

訳注

前書き

背景