iSCSI over iSCSIではまる？
iSCSIディスクを便利に使っているのだが、ネットワークの関係で
iSCSIでマウントしたディスクの上にStarWindのソフトウェアiSCSIターゲット(Windows)を
載せ、利用するってことをやってた。
うっかり、リブートしたら、パーティションテーブルがぶっ飛ぶという事例が発生。
で、なぜかマウントできなくなる。
iscsi over iscsi が問題なのか、ThinProvisioning が問題なのかは判然としないが、
とりあえず、ディスクをコピーするとマウントできる模様。
ちなみに、 VMware と Xenと同時に発生して暗い気持ちに。
とりあえず、 VMware は、partUtil fixgpt で復活できた。
Xen がまだ問題続いてる。。。うーむ。
DELL 11Gサーバ M610 のファームウェアアップデート騒動
大学では年に1回、電源の確認のため停電がある。
継続的なサービスのためには致命的だ。
それはまあ、しかたないとして、この機会にファームウェアのアップデートやらソフトのバージョンアップやらをやるのが普通になる。
で、今回は、ブレードエンクロージャ M1000e に入ったブレードサーバ M610のファームを上げよう、ということになった。11世代のDELLサーバで、iDRAC6 Enterprize があるので、楽かな、と思って作業開始。
M1000e には CMC っていうコントローラがあるので、このファームウェアも上げる。またiDRAC6 もコツコツ上げる。で、調べていくと、まだ Ether コントローラや Life Cycle Controller やら、BIOS やら、あるわあるわ。段々と、暗い気持ちになってきた。
調べてみると、Server Update Utility (通称 SUU)ってのがあって、これを使うと一発でファームが上げれるらしい。よし、とおもってダウンロード。なんと7Gbyte！
他も調べてみると、Systems Build and Update Utility (通称 SBUU)なんてのもある。SUUとSBUUの違いはよくわからんが、SBUUのほうがサイズが小さいので、こっちをダウンロード、で起動してみた。
うむ？ファームウェアをアップデートする画面にはなったのだが、なぜか、DVDやら USBを求められる。結局、SUUが必要なようだ。それならそれってちゃんと書いておいてくれればいいのに。。。。
画面を見てみると、「Life Cycle Controllerを使えば、SUUなしでファームの更新ができます。」というような内容が表示されている。うむむ？どゆこと？
じゃあ、Life Cycle Controller を使ってみよう、ということで、再起動。実際には、Life Cycle Controller ではなく、Unified Server Configurator (通称 USC)を System Service という項目から起動させる。これはブート時に F10を押せばＯＫ．
さて、USCで Platform Update を行うのだが、なぜか ftp.dell.com でユーザ名とか聞かれる。うーん。わからに。無しでも動くのかな、とおもったら、あっさり動作。どこかに書いておくべきでは？
で、チェックに行くと、多数のファームウェアがバージョンアップが必要なことがわかる。うーん。これはすごい。早速進めようとすると、
"The updates you are trying to apply are not Dell-authorized updates."
なんてエラーが出やがるのです。
早速検索すると、世界中で非難轟轟。どうも、Life Cycle Controller のファームウェアのバージョンが 1.5.5 より低いと、証明書の関係で、エラーになるとのこと。
まったく、なんてこった。
調べてみると、Life Cycle Controller のファームを上げるには、Windows か Linux から行うらしい。でもこのサーバ、XenServer が入ってるんですけどー。
うーむ。困った。
がんばってもう少し調べてみると、DELL のリペアパッケージを入れればいいらしい。
http://www.dell.com/support/drivers/us/en/04/driverdetails?driverid=G3G5F
でも、なぜかアップロードできない。実は UFIのブートになっているとだめなので、USCから抜ける必要があるとのこと。あー、めんどうすぎる。USCは、自動的には終わらなくて、iDRACの中から起動を止める必要があったりするわけです。
で、やっとファームをあげて、USC(System Services)をもう一度立ち上げ、Platform Update を実行すると、無事にファームウェアが上がる（といっても1時間はかかる）、というわけのようです。
（イマココ）
ふう。
OpenStack 雑感
ここ数日、さくらインターネットの専用サーバ上にOpenStack でプライベートクラウドの構築を進めていた。OpenStackの噂が聞こえてきてから、すでに数年たっているので、ずいぶんと安定して使いやすくなっているのでは、と期待して始めたのだが、すぐに裏切られた。
まだまだOpenStackは使いやすい状況ではない。
VMware、XenServer、HyperV、RedHat Virtualization と使ってきたので、それなりに仮想化には知見があるつもりでいたが、OpenStackはまだまだそれ以上に複雑だった。
OpenStack というだけに、様々なモジュールが疎結合になっている。設計としてはカッコ良いのだが、設定は大変。とにかく、あちこちに設定が隠れているのだ。
結局、複雑すぎて設定が大変なので、簡単インストールのためのツールがいくつも作られている。DevStackや PackStackがそれだ。でも、これらはあくまで簡単インストールのためであり、実際に詳しい中身を触ろうとすると、むしろ、どこにどんな設定が入っているか分からない、という問題もある。
で、うっかりさわってしまうと、どうやって回復させていいのかわからない、という問題も生じる。
結局、ある程度わかった時点でえいや、とサービスインして、いろいろなサーバを載せ始めたが、今日は、うっかりホスト側のサーバのネットワークを切断してしまい、全部の仮想サーバの外部ネットワークが切れる、という事態を招いてしまった。
いくつか学んだことを散漫に書いていくが、
・Keystone が結構大事。データベースを生で見るのもあり。
・IPアドレスの変更は大変なので、事前によく設計しておくべき。
（特に、外部向けのＩＰか、内部向けのＩＰか、を良く考えるべし）
・現状(2013/10/17時点）では、Grizzly を使っているが、nova と quantum の切り分けが今一つ。
（まだ nova に余分なコマンドが残っており、わかりにくい）
・cinder を使うためには、最初から lvm 用のパーティションを用意しておくべし。
（今回は、手遅れだったのっで、なんと loop デバイスで逃げている。）
・quantum は、 openvswitch も使っているので、その設定、関係を良く理解しないと
ネットワークが切れる。また、 iptables は手で触りにくくなる。
（/etc/init.d/iptables はやめるべし）
・Horizon は、まだまだ OpenStack の全ての機能が使えるわけではない。
CD-ROM をつけたりはずしたり、とか、いろいろな 仮想サーバ用の管理機能は
ほとんど実装されていない。
というわけで、数日で、コードネームとサービスの対応が頭に入ってしまうほど苦しんだ、ということでありました。一体何をやってんだか。。。
PackStack all-in-one だと、なんと nagios まで入るのだが、中途半端な設定で、またこれも悩まされる。 nrpe （Nagios Remote Plugin Exchange)を使うことになる。また nagios-plugin も、 epel のリポジトリを使うと、コマンド毎に入れることになる。。。
jQueryMobile 経由で submit すると、次のページの .ready() などが動かない
・きっかけはハッカソン
2013/10/12-13 は、名古屋で「シビックハック and Mashup Camp」 をオーガナイズしていた。
オーガナイザなので、あとは、ゆったりと皆さんの開発の様子を見学してればよいかな、と思っていたのだが、ひょんな事から、オーガナイザスタッフ＋審査員で開発することに。
開発中のシステムについてはあらためて紹介することとして、困ったことは、特定のページで javascript が動かない、という現象が発生したことだ。なぜか reload すると動く。javascript のロードの問題かと思い、考えられるあらゆる事にチャレンジしてみたのだが、ダメ。
・問題事象
現象としては、jQueryMobile の form タグ中の button submit で、別のページに遷移すると、そのページの body onload や ready などのJavascript が動かない、という現象。
ハッカソンという時間との闘いの中で、こういった謎の現象に見舞われるのは本当に不幸だ。jQuery submit 関係で検索してもまったく見つからない。
うーん。で、今朝から使っているライブラリを一つずつはずして再現性の検証を行った。すると、特定のjsライブラリを入れるとsubmitが動かない。いろいろ検索した結果わかったのは、jQueryMobileがページ繊維をAjaxで行っている、ということであった。jQueryMobileを真面目に勉強せずに使ったのが悪かったのか。。。「jQueryMobile ajax 遷移」で検索すると、いろいろと情報が出てくる。
結論としては、
<form action="next.html" method="get" data-ajax="false">
と、form タグに、"data-ajax=false" と書くだけであった。あの時間を返して欲しい。。。
Google AppEngine が、Google Apps アカウントの移行で、Deploy できなくなる
ひさしぶりに Google AppEngine のアプリのデプロイをしようとしたら、うまくいかない。
１．slim3 の meta ファイル設定を忘れていた。
２．設定したつもりだったが、他プロジェクト名になっていてうまく動作しない
３．Google AppEngine ライブラリがアップデートしていて、うまくいかない
などなど。とりあえず Eclipseの update をかける。で、再度デプロイ。
しかし、またうまく行かない。
今度は
Unable to update app: Error posting to URL: https://appengine.google.com/api/appversion/create?app_id=xxxxxx&version=1&404 Not Found
なんてエラーが出る。うーむ。いろいろ試す。１晩寝てみる。など、など、色々試し、ネットも見て、最後に解決。
実は、2011/暮れに、Google Apps アカウント(独自ドメイン）のユーザは、一般のgmail アカウントに移行する、という措置がとられてている。
この移行対象のアカウントで、Eclipse からGAE にアクセスすると、テンポラリの名前が付けられて、それがログインアカウントとして記録されてしまう。
その後は、なんどやってもダメ。
実は、Eclipse の GAE plugin 、画面の左下にアカウントを表示している。これを見れば、一目瞭然。テンポラリアカウント名になっているから、ログインに失敗しているのだ。
というわけで、アカウントを再度変更して、無事にデプロイ終了。なんというか、、、、微妙にむなしい結果であった。
