読者です 読者をやめる 読者になる 読者になる

わかりやすい

主にIT関連や時事ネタの興味を持ったことを、なるべくわかりやすく書いてみようとおもいます。

スポンサーリンク

東京都知事選挙 選挙費用はまるまる無駄なのか?

表記の件。

舛添さんの適否とか辞めることの是非は対象外。

何と何を比較すべきか、的外れな記事をよく見かけますが、 「任期を全うした場合」と「そうでない場合」を比較すべきでしょう。 つまり「選挙に50億円かかる、50億円が無駄に費やされた」は正しくない。

任期を全うした場合

もともと4年に1度、約50億円は必要。これが地味に重要。 従って、無投票とか特殊な事情が無い限りは年平均12.5億円はどうしても発生する

2年4ヶ月で選挙になった場合

どう解釈するか難しいところですが、

  • 約50億円が必要になるタイミングが1年8ヶ月前倒された

上記は事実でしょう。で、もう少しいくら無駄になったのか、という観点で考えると、

  • 本来約50億円で4年間維持できていたはずのものが、2年4ヶ月しか維持できなかった
  • 年平均12.5億円で済むはずが、年平均約21.43億円かかってしまった

つまり、年間8.93億円余計にお金がかかる。 在任期間の2年4ヶ月に換算すると20.83億円余計にお金がかかったことになる。

当たり前の話ですが、選挙費用だけ考えれば、短命な政権はコストパフォーマンスが悪いですね。 その金額は今回の例で言えば2年4ヶ月で20.83億円無駄になった、といっていいかなと。

ただの算数の話でした。

ext4はIOストールでデータロスが発生する?

ログちゃんと取ってないけど、以下のような事象が確認できた。

目次

構成

やったこと

  • イニシエータからターゲットにログイン
  • イニシエータ側でパーティションを作成、ext4でフォーマット
  • イニシエータ側でディスク(というかページキャッシュ)にデータを継続的に書き出し(追記)つつ、IOを止める(ターゲット側でネットワークを閉塞する)
  • (IO停止区間。30秒くらい。つまり、IOエラーがアプリに返らない程度。)
  • IOを再開させる(ターゲット側でネットワークを開放する)

期待した動作

追記ファイルをtailしながら。

  • IO停止前は書いたものがそのまま表示される(ページキャッシュに書き込まれ、OSが非同期にディスクにflushする)
  • IO停止中も書いたものがそのまま表示される(ページキャッシュに書き込まれるものの、ディスクへのflushが失敗する。書き込み保留。)
  • IO再開後、書き込み保留していたものも含めてすべてのデータがディスクにflushされる(データの破壊や欠損は無い)

ext4で実際に発生した現象

  • IO停止前は当然問題なし
  • IO停止後、数秒してtailの表示が止まった…(ページキャッシュへの書き込みができなくなった?)
  • IO再開後、書き込みが再開されたものの、データの欠損が発生した

具体的にはsleep 0.1しながらdate >> fileとかで書いているので、

2016年  4月 22日 金曜日 11:37:34 JST
2016年  4月 22日 金曜日 11:37:34 JST
2016年  4月 22日 金曜日 11:37:34 JST
2016年  4月 22日 金曜日 11:37:34 JST
2016年  4月 22日 金曜日 11:37:34 JST
2016年  4月 22日 金曜日 11:37:34 JST←データ欠損!
2016年  4月 22日 金曜日 11:37:52 JST←データ欠損!
2016年  4月 22日 金曜日 11:37:52 JST
2016年  4月 22日 金曜日 11:37:52 JST
2016年  4月 22日 金曜日 11:37:52 JST
2016年  4月 22日 金曜日 11:37:52 JST

イメージ的にはこんな感じ。

xfsでやってみると

欠損しない。tailも止まらない(ファイルというかページキャッシュへの書き込みが継続する)。

まとめ

  • 事実としては理解したが、理由がよくわからない
  • ファイルシステムから見たらデバイスがiSCSIだろうがSCSIだろうがブロックデバイスには変わりないので、他のブロックデバイスでもIOストールでデータ欠損が起きるのでは?
  • 識者の方、推測でもいいので是非お考えをご教示いただきたく…

追記

xfsでも同じ現象が起きた。時間か何かの量かはわからないけど、IOのストール時間が長いとxfsでも書けなくなる。

熊本県で発生した地震時にLINE Outを一部無料化したLINEさんの見解とその考察

表記の件。

目次

おさらい

熊本県で発生した地震時のLINEさんの対応にみる、災害時の通信のあり方 - わかりやすいのおさらいになりますが、

  • LINEさんの「LINE Out 1通話10分まで無料」施策は、結果的に被災地の電話網の不要な負荷増に加担してしまった可能性が高い
  • 届出電気通信事業者とはいえ、電気通信事業を行う会社として、法の趣旨に反した非常に軽率な行動だったと言わざるを得ない

これが当サイトの考察。

今日はここをもう少し掘り下げて、

  • どうして軽率な行動を取るに至ったのか?

ここを考えてみようと思います。

どうして軽率な行動を取るに至ったのか?

原因の仮説を考えてみます。 数字が大きいほど高次元の問題であることを意味します。

  • 1.影響を考えようとする人も仕組みも存在しない
    • 残念ながらレベルが低すぎるといわざるを得ない
  • 2.影響を考えたけど、電話網への悪影響まで考えが及ぶ人材が社内に存在しない
    • 人材・能力不足
  • 3.電話網への悪影響まで考えが及ぶ人材は社内に存在するものの、その人材へ連絡を取る必要性を考えなかった
  • 4.その人材へ連絡を取ろうとしたが、連絡が取れず、スピードを優先して実施に踏み切った
  • 5.その人材へ連絡が取れ、実施すべきでないとしたが、何らかの判断(ほかに考えられるメリットのほうが大きい、等)により実施することとした

さて、ここでLINEさんの見解から、仮説を絞り込んでみましょう。

LINEさんの見解

一時情報源はBuzzFeed Japanさんの模様。

www.buzzfeed.com

関係しそうな部分を、文意が損なわれないと私が考える範囲で引用します。

本施策の実施判断は、LINE Outの通常利用率やこれまでの災害時の無料化実施時の利用増加率、被災地から被災地外へのLINE Out通話・発信については輻輳リスクが低いこと、PSTNのバックボーンを担当している事業者への事前確認、などを判断材料としましたが、最も多くの利用が想定される被災地外から被災地へのLINE Out通話・発信は、輻輳リスクを高めることは事実であり、輻輳リスクを最大限低減させるという点においては、考慮・配慮が充分ではなかったと認識しております。

その告知についても、災害掲示板やテキストメッセージが災害時における優先的なコミュニケーションである点、LINE Out利用は、緊急性が高い場合においても、繰り返しかけない、短い時間で終わらせる、被災地から被災外へのコミュニケーションに限るなどの注意点をお知らせ出来ていなかった点は、可否判断基準とあわせて反省する点、見直しを行うべき点です。

さて、仮説を見直してみましょう。

どうして軽率な行動を取るに至ったのか?

あくまでLINEさんの事後発表なので事実かどうかはわかりませんが、とりあえず信じるとします。

  • 1.影響を考えようとする人も仕組みも存在しない

これは違うようです。赤字で書いたように、ちゃんと影響を考えたと言っています。

  • 2.影響を考えたけど、電話網への悪影響まで考えが及ぶ人材が社内に存在しない

「PSTNのバックボーンを担当している事業者への事前確認」は行っているようなので、影響は考えたようです。 ただ、以下が謎です。

  • PSTNのバックボーンを担当している事業者とは誰で、その事業者に何を確認したのか
    • 当該事業者は何を根拠に何を判断できるのか(被災地の通信状況を把握しているのか)
  • 当該事業者からLINEさんにどういう返答が来たのか、それを踏まえてLINEさんはどう判断したのか

まともな電気通信事業者なら、今回のLINEさんからの確認依頼には「そんなことやってくれるな」と答える気がします。理由は熊本県で発生した地震時のLINEさんの対応にみる、災害時の通信のあり方 - わかりやすいを参照。

というわけで、影響の考え方の着想も含めて人材不足の可能性は捨てきれない。

  • 3.電話網への悪影響まで考えが及ぶ人材は社内に存在するものの、その人材へ連絡を取る必要性を考えなかった

見解に関連事項が含まれず、否定も肯定もできず。

  • 4.その人材へ連絡を取ろうとしたが、連絡が取れず、スピードを優先して実施に踏み切った

見解に関連事項が含まれず、否定も肯定もできず。

  • 5.その人材へ連絡が取れ、実施すべきでないとしたが、何らかの判断(ほかに考えられるメリットのほうが大きい、等)により実施することとした

見解に関連事項が含まれず、否定も肯定もできず。

今ある情報だけでは、これ以上の考察は難しそうです。

せっかくなので、LINEさんの見解を考察

LINEさんは見解の中で、「(以下のような)注意点をお知らせできていなかった点は、可否判断基準とあわせて反省する点、見直しを行うべき点」とおっしゃっています。

  • 災害掲示板やテキストメッセージが災害時における優先的なコミュニケーションである点
  • LINE Out利用は、緊急性が高い場合においても、繰り返しかけない、短い時間で終わらせる、被災地から被災外へのコミュニケーションに限る

お知らせできていなかった理由が「考えていなかった」のか、「考えたけど適切に表現できていなかった」のかはわかりませんが、ここで今一度、施策実施時のアナウンス内容を見てみましょう。

LINEから固定電話・携帯電話にかけられる「LINE Out」機能で、日本国内の番号への発信を1通話最大10分まで無料化しました。家の電話やLINEでつながっていない方への安否確認にご活用ください

この文章を書いた方は、以下のどちらの意図で書いたものか、推測してみましょう。

  • 被災地から被災地外への安否情報の通知・連絡・報告に使ってほしい
  • 被災地外から被災地への安否情報の確認に使ってほしい

ちなみに自分には後者を意図しているのかな、と読み取りました。 もし自分の読み取ったとおりなのであれば、以下が「本当に実施前に行われた検討なのか?」「取材に対して後付け的に考えたものなのではないか?」という疑問が沸いてきてしまいますね。

本施策の実施判断は、LINE Outの通常利用率やこれまでの災害時の無料化実施時の利用増加率、被災地から被災地外へのLINE Out通話・発信については輻輳リスクが低いこと、PSTNのバックボーンを担当している事業者への事前確認、などを判断材料としましたが、最も多くの利用が想定される被災地外から被災地へのLINE Out通話・発信は、輻輳リスクを高めることは事実であり、輻輳リスクを最大限低減させるという点においては、考慮・配慮が充分ではなかったと認識しております。

その告知についても、災害掲示板やテキストメッセージが災害時における優先的なコミュニケーションである点、LINE Out利用は、緊急性が高い場合においても、繰り返しかけない、短い時間で終わらせる、被災地から被災外へのコミュニケーションに限るなどの注意点をお知らせ出来ていなかった点は、可否判断基準とあわせて反省する点、見直しを行うべき点です。

真偽は定かではありませんが、少なくとも自分にとっては、LINEさんに対する印象がぐっと改善するような発表ではありませんでした。

もしよければ、いいね・シェア・ツイート・+等お願いいたします。

熊本県で発生した地震時のLINEさんの対応にみる、災害時の通信のあり方

(2016/04/16 11:30追記) LINEさんから見解が出たので、それについての考察記事を書きました。熊本県で発生した地震時にLINE Outを一部無料化したLINEさんの見解とその考察 - わかりやすい

表記の件。

例によって技術者の立場からの記事ですが、今回は珍しくLINEさんの対応を批判しています。 LINEさんの行動の真意(とりわけ「営業的思惑の有無」)に興味がある方は多いと思いますが、この記事では扱いません。

目次

結論

  • LINEさんの「LINE Out 1通話10分まで無料」施策は、結果的に被災地の電話網の不要な負荷増に加担してしまった可能性が高い
  • 届出電気通信事業者とはいえ、電気通信事業を行う会社として、法の趣旨に反した非常に軽率な行動だったと言わざるを得ない

以下、もう少し具体的に考察していきます。 まずは事実の確認から。

LINEさんが、いつ、何をしたのか

※以下、災害時に取る行動として推奨されない情報が含まれます。記事として読み、災害時の行動の参考としないでください。

2016/04/14(Thu) 21:26頃

熊本県震源とした地震発生

2016/04/14(Thu) 22:21頃 (地震発生から約55分後)

LINEの公式Twitterアカウント「@LINEjp_official」が以下をツイート

2016/04/14(Thu) 23:16頃 (地震発生から約1時間50分後)

LINEの公式Twitterアカウント「@LINEjp_official」が以下をツイート

※誤解が広がらないように削除される可能性があるので、本文のみ以下に引用します。

LINEから固定電話・携帯電話にかけられる「LINE Out」機能で、
日本国内の番号への発信を1通話最大10分まで無料化しました。
家の電話やLINEでつながっていない方への安否確認にご活用ください。
#熊本 #地震 #拡散希望

以降、上記ツイートに返信が多数寄せられる。 その大半は「電話網に負荷を掛けることになる」ことを懸念した、批判的な内容。

2016/04/15(Fri) 01:50頃 (無料化案内から約2時間34分後)

LINEの公式Twitterアカウント「@LINEjp_official」が以下をツイート

[https://twitter.com/LINEjp_official/status/720655437729673216:embed]

※なぜか展開されないので引用

安否確認の連絡は、まず通信量の少ない災害伝言板やLINEトーク等をご利用ください。
https://t.co/GGBjQj7RRQ 
先ほどご案内したLINE Outは回線に負荷が集中する恐れがあるため、
緊急性が高い場合のみご利用いただくようご協力をお願いします。
#熊本 #安否確認

災害時に通信はどうあるべきか

そもそも通信ってどうやって成り立ってるんだっけ

通信は通信用の設備で成り立っていますが、通信用設備にはキャパシティ(許容量)があります。 「同時にx回線まで利用可能」とかですね。

キャパシティが高ければ機器は高価になりますし、逆に低ければ機器は安価になります。

稼働率(キャパシティに対してどれだけ利用されているか)を高くすると儲けがたくさん出ますから、通信会社としてはなるべく安い機器にたくさん通信をさせたいわけです。 ただ、ケチりすぎると通信がパンクしてしまうので、その通信設備に期待される通信量に応じて、適切なキャパシティの通信設備を用いています。

どういうときに通信が成り立たなくなるんだっけ?

通信設備の故障が一番わかりやすいですが、それ以外に「通信したい人の数が通信設備のキャパシティを超える」という状況が考えられます。 人気アイドルのコンサートチケット発売時刻とか、新年が明けたし瞬間とか、今回みたいな災害発生時の安否確認とかで発生します。

通信したい量が通信設備のキャパシティを超えると、通信設備がパンクしてしまいます。専門用語では輻輳(ふくそう)」といいます。

輻輳すると何が起きるかというと、「使える人の数がキャパシティを大きく下回る」ことになります。 不思議ですね、キャパシティに近い性能くらいは出てほしいんですが、そうではないんです。

ところで輻輳が起きたとして、そこで行えなかった通信はいろんな内容がありますよね。 災害時にどんな通信があるのか。

  • 普通の日常的な通信
    • 災害があろうが無かろうが、行われている通信
  • 安否確認
    • 心配だけど、この通信ができないことが原因で人が死ぬことは無い
  • 救助要請(119番
    • この通信ができないと、それが原因で助けられた命が助けられないことがある
  • 二次被害予防のための警察・行政機関等への通信
    • この通信ができないと、それが原因で新たに命の危機を生むことがある

災害時、どの通信が優先的に扱われるべきか、こうやって並べると誰でも簡単に判断できますよね。

輻輳を防ぐために、誰が何をするのか?

さて、本題に近づいてきました。 通信設備を守るために、誰が何をするか。

通信事業

一番の主役です。NTT東西さんとか、ドコモさん、KDDIさん、ソフトバンクさん、あとNTTコミュニケーションズさんあたりが対象ですね。 彼らは「重要通信」を守ることを目的に、輻輳を防ぐ」をために「必要最小限度の通信の制限」を行います。 これにより、重要通信以外はキャパシティが逼迫している通信機器に到達しなくなります。 ちなみに重要通信を守るための通信の制限は、電気通信事業法において彼らに課された「義務」です。

通信利用者

電話やLINEを使っている我々ですね。どうあるべきか、でいうと、

  • 救援要請等は遠慮なく行う
  • 重要通信の邪魔になるような通信は極力行わない

これに尽きると思いますが、これって具体的に何をどうすればいいのか、難しいですよね。 考えるための材料を少し整理してみます。

  • 輻輳しにくい通信手段を選ぶ

電話(通話)よりSMS(ショートメッセージ)、SMSよりインターネット(LINEとかSkypeとかTwitterとかFacebookとか)です。

「インターネット」は、「(電話やSMSが使う)電話網」より通信のキャパシティが大きいケースが多いですが、例えばインターネット用の通信線が切れた場合など、インターネットも輻輳するときは輻輳します。以下も是非参考にしてください。

  • 少ない通信量で用件を済ます

動画より静止画や音声、静止画や音声よりテキストメッセージが通信量が少なく、通信設備にやさしいです。 また、動画や音声の再生は携帯端末の電池をテキストよりも多く消費します。 なるべくテキストメッセージがいいでしょう。

  • うまく通信できないときは

輻輳している可能性があります。 短時間に何度も再挑戦しようとすると、輻輳の復旧を遅らせてしまうことになります。 電話にせよSMSにせよインターネットにせよ、うまく通信できないときは少し時間をおいてから再挑戦しましょう。それだけで輻輳の回復が早くなります。

LINEさんの対応はどうだったのか

LINEさんは「LINE Out」という機能を条件付きで無料化し、安否確認にLINE Outを使うように推奨していましたね。 「LINE Outは」調べたところ、「(インターネットにつながった)LINEが動いているスマホと電話網の間で電話をさせる」機能のようです。

みんながLINE Outで安否確認を行ったらどうなりますかね。 今回の件で言えば、熊本の電話の通信設備にLINE Outから通信が流入することになります。

今回、熊本で輻輳が発生したかどうか、通信事業者が重要通信を守るための通信制限を行ったかどうかは私は調べていませんが、どちらも発生しない・行われない方がいいのは当たり前です。

LINEさんの今回の対応は、輻輳の発生や通信制限の発動を加速させる方向の対応でした。 これはとてもよくない。

電気通信事業の観点から見るLINEさん

LINEさんは「電気通信事業法」の規程する「届出電気通信事業者」のようです。

linecorp.com

届出電気通信事業者A-20-9913

LINEさんの今回の対応は電気通信事業法上は違法ではないと考えます。 (詳細は要望がたくさんあれば書こうと思いますが、ややこしいのでとりあえず省略します。) ただ、法の趣旨に反した行為であったと考えます。以下、電気通信事業法の目的を引用します。

(目的)
第一条  この法律は、電気通信事業の公共性にかんがみ、
その運営を適正かつ合理的なものとするとともに、
その公正な競争を促進することにより、
電気通信役務の円滑な提供を確保するとともにその利用者の利益を保護し、
もつて電気通信の健全な発達及び国民の利便の確保を図り、
公共の福祉を増進することを目的とする。

地震発生の直後から自分たちにできることを考え、 地震発生の1時間50分後にアクションを起こしたその迅速さにはとても敬意を表します。

ただ、今回の施策は重要通信の確保を妨げかねない軽率な行動だったと思います。 しかも、LINEさんは(届出電気通信事業者とはいえ)電気通信事業者でした。

届出電気通信事業者は、簡単に言えば「電話ほど品質が求められない、ライトな事業者」です。 (詳細は電気通信事業法を読んでいただければと思います。) 電気通信がどうあるべきかについて、電話屋とインターネット屋(老舗大規模ISPを除く)では向き合い方が全く違います。 奇しくもLINEさんは、「自社がいかに電気通信事業を理解していないか」「届出電気通信事業者の中には、電気通信事業法の目的すら理解していない事業者が存在する」という二つの事実を明々白々にしてしまいました。

LINEさんの今後の改善に大いに期待したいと思います。

(2016/04/16 11:30追記) LINEさんから見解が出たので、それについての考察記事を書きました。[http://wakariyasui.hatenablog.jp/entry/2016/04/16/112037:title]

よろしければシェア・ツイート等お願いいたします。

以下、うんちく

電話屋とインターネット屋の通信品質に関する考え方の違い(LINEさんに同情する方向の技術的考察事項)

例によって推測を含みます。

インターネットにおける通信品質の考え方と、電話における通信品質の考え方にはかなりギャップがあります。 電話は(輻輳が起こる通信設備の役割にもよると思いますが)

これが基本的な対応方針です。

一方のインターネット(とりわけ、コンテンツ屋やアプリ屋)はというと、

  • 増強

これが基本的な対応方針です。なぜか。

  • 輻輳とか通信制限で発生する機会損失による経済的ダメージが大きい
  • 増強が電話に比べて容易・安価

つまり、コンテンツ屋・アプリ屋には「通信を区別」して「特定の通信を守る」という文化が希薄なんです。
(実効的かどうかはさておき、インターネットにおいて通信を区別したり特定の通信を守る技術はもちろんありますし、通信屋寄りのインターネット屋はそれらを駆使して、相応の価値を社会に提供しています。)

また、電話(VoIP)で発生する通信量は、彼らが扱う総通信量に比べたらゴミみたいなものです。 ちょっと(数万)呼が発生しただけで通信設備に影響が出るなんて、というのが、 今回施策のゴーを出した方の本音かもしれません。
(少なくとも電気通信事業法に明るい方が意思決定に携わっていらっしゃれば、ゴーが出ることは無かったでしょう。)

ソフトバンクさんの例

日本には、「大規模災害発生時における公衆無線LANの無料開放」を行う仕組みがあります。

[http://www.wlan-business.org/customer/introduction/feature/00000japan:title]

公衆無線LANの関連事業者が主体的に行っています。

ほかの事業者さんも無料開放を開始しているかもしれませんが、ソフトバンクさんの記事が最初に目についたので、一例として。

[http://www.softbank.jp/corp/group/sbm/news/info/2016/20160415_01/:embed:cite]

災害時にインターネットが使える(結果的に電話への負荷も軽減される)ことが重要であることは東日本大震災の教訓でもあり、 ソフトバンクさんをはじめ、きっちり運用されている通信事業者の方々に敬意を表します。

東日本大震災時の例

電話屋以外でも、災害時等に通信の品質をしっかり考えている企業は存在します。

[http://morioka.keizai.biz/headline/873/:embed:cite]

電気通信事業についてIIJさんとLINEさんを比べるのは酷ですが、 法の趣旨をきちんと理解しているIIJさんとLINEさんの対応の違いには、学ぶところがありそうです。

 ITソリューションを手がける「インターネットイニシアティブ(IIJ)」(東京都千代田区)は3月16日、
東日本大震災の発生を受け、岩手、宮城、福島各県の自治体のミラーサイトの無償提供を始めた。

 各自治体へのアクセス集中による負荷を緩和するのが目的で、
地震発生後、閲覧が困難だった自治体ホームページが見やすくなる。

ミラーサイトは現在、市町村のみ公開されており、順次全ての自治体へ広げていくという。

 同社広報担当者によると
「福島県のように、ミラーサイトを構築する前に既にサーバーダウンしてしまったところもあり、
全ての自治体をカバーできていない。特に県はまだできていないが、
各県の広聴広報課と連絡が取れ次第、順次公開していきたい」
と話している。

 ミラーサイトは、同社が今月14日から無償提供しているクラウドサービス
「IIJ GIOホスティングパッケージサービス」を利用したもの。
設備が関西にあることから、東北や関東地域の電力不足の影響も受けにくいとしている。

この記事の改定履歴

  • 2016/04/15(Fri) 12:20頃 ソフトバンクさんの例を追記、一部目次構成を変更

kvmでストレージパスを変更してのライブマイグレーション

やりたいことがタイトルで表現できているかどうか謎ですが、概要は以下の通りです。

目次

何をやりたいのか

  • KVM Host A(以下HA)からKVM Host B(以下HB)にGuest X(以下、GX)をライブマイグレーションしたい
  • その際、ストレージパス(ディスクパス)を変更したい
    • 例えば以下のようなケース
      • HAではGXのストレージが/path/to/gx.imgだったとする
      • HBではGXのストレージを/path/to/gx2.imgとしたい、というケース
    • ストレージパスが変わる、ということはつまり(ほとんどの場合は)「共有ストレージを用いたライブマイグレーションを行わない」ということ

上記ができると何がうれしいのか?

例えば

  • iSCSIベースのストレージからファイルベースのストレージに切り替える
  • 冗長化のためにdrbdを噛ませたい

とか。

アプローチ

  • ストレージを丸々コピーするマイグレーション方式を利用する(virshの--copy-storage-allオプション)
  • 移行先で有効になるxmlを指定する(virshの--xmlオプション)

具体的な手順

冒頭の「何をやりたいのか」の例を当てはめつつ説明します。

1. 移行先ホストで、移行先ストレージを用意する

例では以下になります。

  • HB上で/path/to/gx2.imgを用意する

2. 移行元ホストで移行対象の仮想マシン定義を出力、移行先用に書き換える

例では以下になります。

  • HA上でGAの仮想マシン定義をdumpする(virsh dumpxml 仮想マシン名 > ダンプ先ファイル名)
  • 移行先用に仮想マシン定義を編集する(上記の「ダンプ先ファイル名」で指定したファイルを編集する)
    • 編集内容は「ストレージパスの書き換え」
    • 例えば以下のようなこと
(snip)
 <domain type='kvm' id='X'>
 (snip)
   <devices>
     (snip)
     <disk type='block' device='disk'>
       (snip)
-      <source dev='/path/to/ga.img'/>
+      <source dev='/path/to/ga2.img'/>
       (snip)
     </disk>
   (snip)
   </devices>
 (snip)
 <domain type='kvm' id='X'>

ここでは「ダンプ先ファイル名」をga.xmlとします。

3. マイグレーション

例では以下になります。

コマンドにするならこんな感じ

HA# virsh migrate --live --persistent --copy-storage-all --verbose --xml ga.xml GuestA qemu+ssh://HB/system

これでライブマイグレーションできるはず。

注意点

いろいろ問題点があります。

  • 長い時間、ストレージとネットワークに負荷がかかり続ける
    • ストレージ内容をネットワーク経由で全部コピーすることになるので、シンプルにやるならこの特性はやむなし

こんなもんだろうか…。

しかしとりあえず、時間がかかっても「止めずに、別ストレージパスに移行できる」というのはかなりメリットな気がする。

drupal8のインストールが途中で振り出しに戻る

drupalのインストールをしていたのですが、表記の事象に遭遇。 ちなみに振り出しに戻る、というのはリダイレクトでブラウザでのインストールの最初の画面に飛ばされる、という意味です。

前提

  • Ubuntu 14.04 LTSにdrupal8.0.6をインストールする
  • 前段にリバースプロキシが存在する←結論を言うとこいつが原因

事象

drupalのインストールは概ね以下の手順になります。

  • OSをインストール
  • 必要なパッケージ(apache, php, mysqlとその関連)
  • drupalのダウンロード&展開&Apacheから見えるようにする
  • ブラウザで当該サーバにアクセス、設定が進んでいく

どこで表記の事象が起きるかというと、ブラウザで当該サーバにアクセスした後。具体的には以下。

  • 言語の選択
  • プロフィールの選択
  • 必要条件の検証
  • データベースのセットアップ←このステップの次で「言語の選択」に戻される
  • サイトのインストール
  • 翻訳のセットアップ
  • サイトの環境設定
  • 翻訳の完了

対処

drupalのパッケージを展開した後、sites/default/default.settings.phpを以下のとおり編集する

(snip)
-# $settings['reverse_proxy'] = TRUE;
+$settings['reverse_proxy'] = TRUE;
(snip)
-# $settings['reverse_proxy_addresses'] = array('a.b.c.d', ...);
+$settings['reverse_proxy_addresses'] = array('a.b.c.d');

ちなみに上記のa.b.c.dは、drupalが実際に動いているサーバから見える、リバースプロキシのIPアドレスと思われる。

原因

もはや対処で解決しちゃった人は興味がないと思いますが、原因の推測。 ちゃんと追いきっていませんので内容は薄っぺらです。

どうやらインストーラはリダイレクトとかを巧みに使っているようで、 リバースプロキシが存在すると、それがうまく動かない模様。 エラー時にphpが「header already sent」的なエラーを吐いていました。

ちなみに、かなりハマった…。いろいろ調べた。

  • phpのエラーログを有効にしてみた
  • エラーで特定したファイル・行を確認してみた
    • ある箇所Bでヘッダ出力しようとしたとき、ある箇所Aですでにヘッダ出力されていることはわかった
    • しかし、それがなぜだかわからない…
  • サーバとかクライアントでパケットキャプチャしてみた
  • 手元のVirtualBoxdrupalをインストールしてみた
    • うまくいった
  • VirtualBoxと問題が起きている環境でインストール時のパケットキャプチャをして比べてみた
    • 失敗しているほうはTCPのRSTが頻発。これがリバースプロキシの有無と関連しているかどうかは不明
  • ためしに問題が起きている環境でリバースプロキシをはずしてみた
    • うまくいった
  • ようやく以下にたどりつく

やっと解決。ちなみに関連エラーは以下のとおり。

振り出しに戻される(リダイレクトされる)ときにphpのエラーログに出力される内容

RuntimeException: Failed to start the session because headers have already been sent by "/path/to/drupal-8.0.6/vendor/symfony/http-foundation/Response.php" at line 1151. in /path/to/drupal-8.0.6/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php on line 144

これはもはやdrupalとは関係なくなってきていて、罠。この先に答えは見つけられませんでした。

振り出しに戻されたあと、再度インストールを進めた際に途中でブラウザに表示される内容

Error
The website encountered an unexpected error. Please try again later.
Drupal\Core\Config\UnmetDependenciesException: Configuration objects (block.block.bartik_account_menu, block.block.bartik_branding, block.block.bartik_breadcrumbs, block.block.bartik_content, block.block.bartik_footer, block.block.bartik_help, block.block.bartik_local_actions, block.block.bartik_local_tasks, block.block.bartik_main_menu, block.block.bartik_messages, block.block.bartik_page_title, block.block.bartik_powered, block.block.bartik_search, block.block.bartik_tools, block.block.seven_breadcrumbs, block.block.seven_content, block.block.seven_help, block.block.seven_local_actions, block.block.seven_login, block.block.seven_messages, block.block.seven_page_title, block.block.seven_primary_local_tasks, block.block.seven_secondary_local_tasks, block_content.type.basic, comment.type.comment, contact.form.feedback, core.entity_form_display.block_content.basic.default, core.entity_form_display.comment.comment.default, core.entity_form_display.node.article.default, core.entity_form_display.node.page.default, core.entity_form_display.user.user.default, core.entity_view_display.block_content.basic.default, core.entity_view_display.comment.comment.default, core.entity_view_display.node.article.default, core.entity_view_display.node.article.rss, core.entity_view_display.node.article.teaser, core.entity_view_display.node.page.default, core.entity_view_display.node.page.teaser, core.entity_view_display.user.user.compact, core.entity_view_display.user.user.default, editor.editor.basic_html, editor.editor.full_html, field.field.block_content.basic.body, field.field.comment.comment.comment_body, field.field.node.article.body, field.field.node.article.comment, field.field.node.article.field_image, field.field.node.article.field_tags, field.field.node.page.body, field.field.user.user.user_picture, field.storage.node.comment, field.storage.node.field_image, field.storage.node.field_tags, field.storage.user.user_picture, filter.format.basic_html, filter.format.full_html, filter.format.restricted_html, node.type.article, node.type.page, rdf.mapping.comment.comment, rdf.mapping.node.article, rdf.mapping.node.page, rdf.mapping.taxonomy_term.tags, taxonomy.vocabulary.tags) provided by standard have unmet dependencies in Drupal\Core\Config\UnmetDependenciesException::create() (line 89 of core/lib/Drupal/Core/Config/UnmetDependenciesException.php).
Drupal\Core\Config\UnmetDependenciesException::create('standard', Array) (Line: 465)
Drupal\Core\Config\ConfigInstaller->checkConfigurationToInstall('module', 'standard') (Line: 136)
Drupal\Core\ProxyClass\Config\ConfigInstaller->checkConfigurationToInstall('module', 'standard') (Line: 146)
Drupal\Core\Extension\ModuleInstaller->install(Array, ) (Line: 87)
Drupal\Core\ProxyClass\Extension\ModuleInstaller->install(Array, ) (Line: 1560)
install_install_profile(Array) (Line: 648)
install_run_task(Array, Array) (Line: 526)
install_run_tasks(Array) (Line: 116)
install_drupal(Object) (Line: 39)

これはこれでぐぐるとそこそこ情報が出てきてしまい、罠。この先に答えは見つけられませんでした。

おまけ

自分のサーバは非力でインストールにすごく時間がかかります。 結果的に途中でHTTPがタイムアウトしてインストールが失敗してしまいました。

リクエスト処理時間が数時間? - HTTPサーバのタイムアウト設定について - — ありえるえりあ

上記を参考にいろいろ調べたところ、タイムアウトが発生しているのはクライアントとリバースプロキシの間。 つまり、バックエンドのWebサーバからの返事が遅すぎるので、リバースプロキシがクライアントにタイムアウトを返しちゃっている、ということのようです。

そんなわけで、リバースプロキシのタイムアウト設定を変更。

https://httpd.apache.org/docs/2.2/ja/mod/mod_proxy.html#proxytimeout

これでプロキシ時のタイムアウトを長くして問題が発生しなくなった。

2016/04/04頃にWindowsの時刻が1時間くらい進んだ件の対処方法

目次

あらまし

wakariyasui.hatenablog.jp

に書いた件の関連。 原因特定までは至っていませんが、自分のように

  • Windowsを使っている
  • Windowsの時刻同期先サーバを、標準のtime.windows.comにしている

という場合、関係者は自分かMicrosoftさんしかいないわけで、しかも自分は特別何か時刻同期について設定をいじっているわけでもないので、 Microsoftさん側の問題なのかな、というところで落ち着いています。

対処方法

さて、対処方法。 何に対する対処か、ですが、2つ考えられると思っています。

  1. (応急対応)とりあえずずれた時計を直す
  2. (再発防止)時刻同期先サーバを変更する

A. とりあえずずれた時刻を修正する

まずはさておき、直しましょう。 直し方は2パターン。 Windows 7を前提に説明しますが、ほかでも似たような方法で対処できると思います。

Aa. 手動で時刻設定を行う

  1. タスクトレイの時刻をクリック、「日付と時刻の設定の変更」をクリック(もしくは、「コントロールパネル」→「時計、言語、および地域」→「日付と時刻の設定」をクリック)
  2. 「日付と時刻の変更(D)...」ボタンを押下、時刻設定を行う

Ab. 時刻同期サーバとの再同期を強制的に行う

  1. タスクトレイの時刻をクリック、「日付と時刻の設定の変更」をクリック(もしくは、「コントロールパネル」→「時計、言語、および地域」→「日付と時刻の設定」をクリック)
  2. 表示されたウィンドウ上部の「インターネット時計」タブをクリック
  3. 表示されたタブ内の「設定の変更(C)...」をクリック
  4. 表示されたウィンドウ内の「今すぐ更新(U)」をクリック

これで直らなければ、「Aa. 手動で時刻設定を行う」か、Bの対処を検討してください。

B. 時刻同期先サーバを変更する

今回発生した事象とまったく同じ事象が、同じ原因に基づいて発生したとき、同じように時間が1時間ほど進んでしまうことを防ぎます。 これは「今回の事象Microsoftさんの時刻同期サーバであるtime.windows.comが原因」という前提に立っています。 もしそうでない場合、同じ原因であれば同じように1時間ほど進んでしまうことがあるかもしれません。

変更先は「国立研究開発法人 情報通信研究機構(通称NICT)」が運営する、公開NTPサーバがおすすめです。

www2.nict.go.jp

以下、変更方法です。 (NICTの公開NTPサーバ以外に設定する場合は、「ntp.nict.jp」を適宜読み替えてください。)

  1. タスクトレイの時刻をクリック、「日付と時刻の設定の変更」をクリック(もしくは、「コントロールパネル」→「時計、言語、および地域」→「日付と時刻の設定」をクリック)
  2. 表示されたウィンドウ上部の「インターネット時計」をクリック
  3. 表示されたタブ内の「設定の変更(C)...」をクリック
  4. 表示されたウィンドウ内のサーバ欄に「ntp.nict.jp」と全部半角で入力、OKをクリック(OKをクリックする前に、「今すぐ更新(U)」を押してテストすることをおすすめします)

NTPうんちく

NTPとは

NTP(Windowsでは「インターネット時刻」という言葉が近しい意味だと思います)というのは、ネットワーク越しに時刻を同期させるための仕組みです。 サザンオールスターズの「今何時?」「そうね大体ね」よろしく、ネットワーク越しにNTPサーバに時刻を教えてもらいます。

NTPの精度

ところでNTPを使った時刻同期では、どのくらいの精度で時刻を同期できるのでしょうか? 答えは「NTPサーバとのネットワークの安定性に依存する」です。

ネットワークの安定性というのは、具体的には「今何時?」と聞いてから「そうね大体ね」と返事が来るまでの時間の「ゆらぎ」です。 返事が来るまでの「時間(返事が早い、遅い)」ではないですよ、「時間のゆらぎ」です。専門用語では「ジッタ(jitter)」といいます。 ちなみに、返事が来るまでの時間は「遅延」とか「RTT(Round Trip Time)」といったりします。

(以下、概念的な話で正確なNTPプロトコルの動作を説明していません。詳細は参考文献を参照ください。)

例えば何回「今何時?」と聞いても、確実に1.00秒後に回答が返ってくるようなネットワークの安定性だった場合、 返ってきた答えから1.00秒を引いた時刻を設定すれば、NTPサーバと誤差0.01秒以内で設定できることになります。

例えば「今何時?」と聞いた際、1回目は0.01秒後に、2回目は0.10秒後、3回目は0.01秒後に返ってきたとします。さて、返ってきた答えから何秒引いた時刻を設定しましょう?

0.01秒とか0.20秒とか早く答えを返してくれるよりも、10.00秒かかったとしてもゆらぎ(ジッタ)が小さい方が正確な時刻設定ができるんですね。

参考文献