最近Google Application Engine(GAE)のテストをしている中で、ファイルを書き込む場合はローカルストレージには書けないので「Google Cloud Storage」(GS)に書き込めという話を知ったというか色々試した。なお例によってPHP。

 ローカルストレージではないどころか汎用的なプロトコルで行われるものでもない(※中身は知らないが)のでPHPからGSの”バケット”にアクセスするためにはいくつか約束事を経由する必要があったが(php.iniに「google_app_engine.allow_include_gs_buckets」の設定が必要、アクセス先は「gs://[GAEアクセスURL]/[対象バケット]」にする、等)、それさえやればフツーに読み書きできた。

 ・・・のだがよく見たらあんまりフツーではなかった。
 改めてGAEのファイルアクセスに関する記述を見ると、「一度クローズしたファイルに”追記”することはできないよ。その場合完全上書きになるよ」的なことが書いてある。
 試しにfopenを色々なモードで試したところ、とりあえず以下っぽいことが判明。
  • 追記モードである「a」はfopenでfalseとなる。
  • というか読み書きモードである「r+、w+、a+」も軒並みfalseとなる。ロックの兼ね合いか?
  • 実質的に使えるのは「r、w」のみ

 なのでログファイルのようにデータを貯めていくファイルについては「一度全読み込み→全書き」という手段を取らねばならないため、量次第ではあるが実質的にはナンセンスだろう。書き込む度にファイルを新規に作成していくのを許すようなデータか、一時ファイルといった利用がメインだろうか。どっちにしろ無料枠は5GBだしね。

追記:
 とゆか別のページに使えるファイル系関数の情報が載っててfopenのパラメータ指定もされてるわ。

関連タグ:Googleクラウド
2016-05-20 [技術]

 試用していたCloudStack4.0.2がある程度落ち着いたので、最新版での運用が可能か今度は4.2の検証をしてみた。というかしている。まだやり切れてるわけではないけど取り敢えず現状で把握したことなど。なお例によって間違いや嘘が交じる可能性があるのでご注意。
 なお環境としては引き続きCentOS6.4のKVMベース。NICが2枚あるPCサーバ3台(管理x1 ホストx2)で構築。ホストは2枚のNICのそれぞれにIP持ちのブリッジcloudbr0、cloudbr1を設定(つまりインストールマニュアルとはNIC構成が異なる)。

  • 基本的な雰囲気は4.0系列と同じような感じ。それほど違和感なく進められる。
  • 名称、コマンド等が「cloud~」から「cloudstack~」に変更。初期DB投入スクリプトが「cloudstack-setup-databases」になったのとか。
  • システムVMイメージのダウンロードURLが4.0系列からは変更されてる。まあマニュアルに従ってインストール進めてれば問題なし。
  • 4.0系列では「yum install cloud-agent」でKVM関係までインストールされた(ような気がする)が4.2だと入らない模様。別途「yum install kvm」で追加する。
  • 4.2に限ったことではないが、自動で入るiptablesの状況(ブリッジに対するFORWARDのDROP等)次第ではシステムVMが外部にアクセス出来ない事がある。しかもそのiptable設定が入るタイミングがよくわからない。(投入直後は大丈夫だったのに翌日になったらダメになってたとか)
→投入タイミングは色々ある模様。例えばマイグレーションを行なった時に受けた側のホストはiptablesの設定が書き換わる。
→iptable設定を書き換えるスクリプトは「/usr/share/cloudstack-common/scripts/vm/network/security_group.py」である模様。
 上記ファイルの下記をコメントアウトすればブリッジに対するFORWARDのDROP処理は停止する。
→もちろんこれがセキュリティ的に、且つどの環境でも正しいかは不明。無条件許可が正しいとは思えない一方で、ブリッジはいわばスイッチだから無条件で止められても困るよなぁと。
  • 手動で入れる主なiptables設定は管理・ホスト側とも4.0系列と同じ。
  • ホスト投入直後だとシステムVMを含むインスタンスの作成にコケるのも一緒。もうクラスタにホストを追加したらagent、libvirtdは再起動するのはデフォにした方が良い気がしてきた。
  • ひと通りゾーンの基本設定を終えた後にじゃあホストを追加しようとしたところ「Guid is not updated for cluster with specified cluster id; need to wait for hosts in this cluster to come up」とゆーエラーが出て追加が出来なかった。
→とりあえず原因を突き詰めると、当該クラスタの情報テーブル「cluster」の「guid」が「NULL」なっていることが原因の様子。
→このguidはクラスタ生成直後はNULLで、その後ホストを追加するとよくあるランダムげなidが投入される。どこか別のテーブルとリンクしてるかは不明。とりあえず「host」テーブルとリンクしてる箇所はない模様。
→どうもこのguid、初期のホストの作成に失敗→その後手動で再設定や強制接続を行なってホストを有効にした場合は入ってくれないらしい。
→初期ホスト投入時のみNULL値を無視すると思われる。その後は「ホスト投入が完了してない」と判断して上記エラーが出る、のか。
→とりあえず暫定的な手法として、当該クラスタのguiidになんでもよいので適当な値を代入しとけばこのエラーは出なくなりホストの追加が可能になる。ぶちゃけ以下の状態でも可。
   update cluster set guid='a' where id=[当該クラスタのID]
→もちろんこんなのが良いとはとても思えない。なんかリンクしてるところがあるならそこから引っ張ってきたいし、そうでないにしても従来のフォーマットに基づいた値を投入したいところ。
→あるいは 「初期状態」と判定させられれば良いのだろうが、それを判定しているフラグはテーブル内にはなさそう。詳細はプログラムを追わなければわからないか。
→なおこのguidは特にその後の操作(更なるホスト追加等)で上書きされることはない。
→ただし、クラスタ内から全てのホストを削除するとまたNULL値が入る。こうなるとまた同じエラーが出てホストの追加が出来なくなる。こうなったらクラスタも消して再作成した方が多分速い。

2013-12-10 [技術]

 タイトル通り。久々に技術ネタ。とあるシステム一群をKVMで構築するに当たり管理性の向上を目的として導入を検討。OpenStackじゃないのかとゆー話もあるわけだが、構築後に扱う人間がCloudStackベースの商用サービスを使った経験があったので。
 バージョンは参考として購入した「CloudStack徹底入門」がベースとしている4.02を使用。またハイパーバイザは上述の通りKVMを前提。当然間違いや嘘が混じっている可能性があるので注意。


  • インストールはリポジトリを追加した上でyumのみで可。ただし各関連アプリやOS、セキュリティに対する設定変更が必要。なおyumは重いw
  • 一般的には構築に必要なサーバは「最低2台」と言われる。CloudStackそのもので言った場合、管理用の「management」とハイパーバイザに入る「agent」の2種類があるため。この2つを1台のサーバにインストール・設定できれば1台でもいけそうな気はするが未確認。
  • 構築後、「ゾーン」と呼ばれる管理領域単位で物事を進めていくことになるのだが、その中で幾つか役割の異なるネットワーク(セグメント)を設定していくことになる(パブリック、ゲスト、管理、ストレージ等)。で、最初コレを全て同一のセグメント(IPはずらした)で構築しようとしたのだが、どうもそうすると「システムVM」が正常に起動してくれない。資料的には「各ネットワークは分けたほうが良い」的な記述があるのだが、分ける以前に単一のネットワークはできないのかもしれない。
  • ただし、上記は構築を始めた初期の頃にハマってた話なのでちゃんと作れば大丈夫な可能性も。結構システムVMは他の場合でも上手く起動しないことが多かった。
  • インストール直後、まずゾーン作成ウィザードから諸々を作成するのだが、どうも「インストール直後の一発目は『ホスト』作成に失敗する確率が高い」模様。agent及びlibvirtdの初期状態から最初の設定投入が上手く反映されてないような気がする。ホスト作成のパラメータに間違いがないのにホスト作成で止まる場合は一度諦めてキャンセル。それでも管理画面的にはホストが作成されてるよーに見えるので、その状態で「agentを停止→libvirtdを再起動→agentを起動」してから管理画面のホスト情報から当該ホストの「強制再接続」もしくはホストの再作成を行うと上手くいく場合がある。その後プライマリストレージ、セカンダリストレージを手で作成する。
  • 下記に述べた設定変更とかを行う場合、管理画面から「ゾーンの無効化」を行なってからにする。こうしないとシステムVMの破棄とかが出来ない。
  • 「システムVM」。CloudStack環境を実現するために自動で生成される仮想マシン群。主だったところでは作成された仮想OS(インスタンス)の画面を擬似的にWebで表示するための「コンソールプロキシVM」と、セカンダリストレージを管理する「セカンダリストレージVM」があるわけだが、設定のバランスで、特にセカンダリストレージVMが起動に失敗し、消滅→自動再作成を繰り返す場合がある。とりあえず私の対処方法は以下の通り。
  1.  agent→libvirtdの再起動。特にagentのログに「x-xx-xxのcgroupを作成できません:そのようなファイルやディレクトリはありません」とゆーログが延々と出る場合はコレでなおる可能性がある。
  2.  プライマリストレージのマウント状態の確認。色々設定をいじったり再インストールを行なったりする中で、agentがプライマリストレージをマウントしっぱなしの場合がある。その状態でゾーンを一から再作成しようとするとagentが新たにマウントを試みる段階でエラーとなる。同じ所を同じ名前でマウントするんだからそのまま進んでくれれば良さそうなものだが、どうも「マウントできなかった」事自体をエラーと捉えるようで先に進んでくれない。ログに「ファイル '/mnt/[長ったらしいID]' を開けませんでした: そのようなファイルやディレクトリはありません」と出つつ、「df -h」でそのフォルダがマウントされている場合にこの可能性が高い。なお単純にマウント先に問題があっても同じログが出ると思われるので注意。
  • またセカンダリストレージVMが起動していても「テンプレートに標準テンプレート(CentOS5.5)が表示されない」「表示されてるんだけど利用可能状態にならない」と場合がある。こうなるとISOの登録もできない場合が多い。この場合原因はネットワーク設定にある可能性が高い。
  1.  セカンダリストレージVMが外部(インターネット)とアクセスできない場合:特に標準テンプレートは最初にインターネットからダウンロードできる必要があるため、パブリックネットワークの設定に問題があると先に進んでくれない。この場合初期データとして標準テンプレートの情報はあるため「表示されてるんだけど利用可能にならない」状態になる。セカンダリストレージVMからでもインターネットにアクセスできるIPが割り振られるようにすると解決する。(ただISOの登録はこの状態でもできるかも)
  2.  いわゆる「ストレージネットワーク」の設定が間違っている場合:KVM構成の場合、事前にハイパーバイザ側のネットワークにブリッジ(cloudbr0、cloudbr1等)を構築し、各ネットワークに割り当てることになるのだが、このブリッジを複数設定し、パブリックや管理・ストレージを分離しようとした場合に、各ネットワークに対するこのブリッジを正しく設定しないと対象ネットワークへ流すべきインターフェースが異なる事になり、通信ができない状態となる。まずは各ネットワークとブリッジの関係が正しいか確認する。また、何らかの理由で「管理画面から設定した後にホスト側で『cloud-setup-agent』コマンドをノーオプションで実行」すると、基本的にはその時のagent.propertiesの内容を元に再設定してくれるのだが、本来「guest」「private」「public」に分かれているネットワークデバイスの設定を1つにまとめてしまう。この場合一度システムVMを破棄した上でagent.propertiesの値を正しいものに変更した上でゾーンを再起動する。
  • システムVM系が正常に動かないとコンソールVMが動かない場合もあり、その場合セカンダリストレージVMとかの詳細設定も見えないのだが、とりあえず起動に成功していれば、各システムVMが稼働しているホスト上から以下のSSHでログインする事が可能。特にネットワークの不通系エラーを把握するのに有効。
 ssh -i /root/.ssh/id_rsa.cloud -p 3922 [ローカルリンクアドレス]  ※ローカルリンクアドレスは各システムVMの詳細設定から確認可能
  • 初期設定でシステムVM用のイメージをダウンロードするとゆー作業が入る。これは一度ダウンロードすれば(nfs的な置き場所さえ同じなら)何度再インストールしてもそのままで可っぽい。(再ダウンロード不要)
  • iptablesについて。インストールマニュアルに初期設定があり、また自動で色々と追加設定してくれるのだが、初期状態だとまずコンソールにつながらない。また作成したインスタンス(ゲストネットワーク)にもつながらない。ただし動作しているホストからは繋がる。ぶちゃけiptablesを停止すれば当然繋がるのだが、とりあえず以下の設定を停止させれば繋がるようになる。KVMの場合、そのブリッジを経由した通信になるので下記の設定を入れられるてはそりゃ繋がるワケがない気がするのだがどうか。どうもKVMデフォルトの「virbr0」を元に設定変更しようとしている?
 -A FORWARD -o cloudbr0 -j DROP
 -A FORWARD -i cloudbr0 -j DROP
  ※「/etc/sysconfig/iptables」内記述。なおcloudbr1以降を設定している場合それも含む。
  ※ただしセキュリティ的に正しいかは不明。一応拡張NWの設定では正しく防いでいる。
  • グローバル設定について。admin管理画面から閲覧&操作が可能な「グローバル設定」。幾つか特徴的なものを。
  1.  「host」:管理マネージャーのIPが指定されるところ、なのだが、デフォルトだと管理マネージャーサーバのデフォルトゲートウェイが指定されるI/FのIPが入ってしまう模様。管理ネットワーク及びI/Fを別にした場合に、ゾーン作成前に事前に変更する必要がある模様。
  2.  「expunge~」:Cloudstackの場合インスタンスを削除しても一定期間残して復帰ができる。デフォルトだと1日保存してくれるが、試験や仮構築の段階でこんなに残されても困るだけである。「expunge」で検索かけて引っかかる設定のうち「86400」となってるものを適宜変更すると吉。
  3.  その他「物理リソースに対してインスタンスに割り当てられる量」とかあって、これも環境によって厳しい場合があるので必要に応じて調整する。
  • よく「管理とストレージネットワークは同一でも可。でもできれば分ける」みたいな記述を見かけるのだが、上述の通りagent.propertiesを見るとネットワークI/Fの指定方法には「guest」「public」「private」の3つしかない。このうち「private」が管理・ストレージであることは明白なので、仮にネットワークを分けてもI/Fを分けることはできない?未確認。
  • 拡張ネットワーク構築時の「負荷分散」について。仮想ルータが行なってくれる仮想負荷分散。だが物理リソースがいっぱいいっぱいの場合、そもそもソレの稼働自体で結構な負荷となる模様。例えばホストが1台の環境で複数のWebインスタンスを生成し分散設定。ab等で大量のアクセスを投げ込むと、親となるホストのLoad Averageが跳ね上がり処理が遅延する。同じ条件で単一のWebにのみ負荷を集中させた方が軽い。
  • ただし上記はあくまでホスト1台をギリギリまで使うようなキツい環境の場合の話。ホストを2台にすると途端に解消され、負荷分散の効力が出る。もちろんその2台の限界値に近づけば話は別だろうが…。
  • 色々やり直す場合話。試行中は何度も再構築することになると思われる。以下が手っ取り早いと思われる。
  1.  management、agent停止
  2.  agentのマウントを解除
  3.  mysqlにログインし、データベースを消去。「drop database cloud」
  4.  DB構築スクリプトの実行。インストール途中で実行した「cloud-setup-databases」を同じオプションで実行する。
  5.  プライマリストレージ内ファイル、フォルダを削除。セカンダリ内はそのままで可。
  6.  ホストのagent.propertiesの中身をクリア(あるいはコメントアウト)。でも「host」の値は変更がなければそのままにしておいた方が良いかも。
  7.  nfsの再起動。
  8.  libvirtdの再起動。
  9.  management、agent起動
  • 上記の再作成の一環でagent.propertiesの内容を全てクリアしてagentを起動した場合、「/etc/init.d/cloud-agent status」で状態を見ると「停止してるがサブシステムがロック」とかイミフな事を言われるが、management側から再設定コマンドが投げられれば改善するのでとりあえずはシカトが吉。
  • ISOの追加について。ISOイメージの追加時に指定できる場所はURL(Web)限定っぽい。マニュアル等には「場合によってはローカルにおける」みたいな曖昧な書かれ方をしているが、「ローカルに置いたWebサーバ」を意味するのか。
  • 当たり前だがあるゾーンに登録したホストは他のゾーンに指定できない。単一のハイパーバイザサーバを異なるゾーンで共有するマネは不可能。
2013-12-09 [技術]

 ほう、それは新しい…のかむしろhtmlの誕生経緯的に見れば原点回帰と言った方がよいのか微妙なところだ。

 例えばコレにhtmlエディタ機能が付加されたりすれば話は大きく違うだろうけども。
関連タグ:Googleクラウド
2013-02-07 [インターネット]

 …単に自称に「ガール」を付けて「まだ若いのようふふ」と主張したいだけなんではとか思う。永遠の17歳的な何か。「クラウド」を意図してを使うような世代が「girl=(通例 17‐18 歳までの)女の子,少女」のわけなうわやめろなにすあらさー
 
関連タグ:クラウド
2011-10-04 [社会]

 今んとこ需要はとても少ないと思われる話。なので分からない人には分からないと思いますが備忘なのでフォロー無しです。また、正しい手法であるかどーかはさっぱり保証しません。

 一般的なアプライアンスを構築する場合、入力のgwとして「IN」を作り、その下に何がしかのアプライアンスを配置するわけだが、この「IN」はそのままだとあくまで「外部からの入力とその戻り」しか通信を行わず、アプライアンス内部から外部へのアクセスは許可しない。そのためやはり一般的には「OUT」を出力のgwとして用意し、外部への出口とするわけだが、この「IN」と「OUT」にはそれぞれ異なるIPを設定せざるを得ないため、グローバルに配置しようとした場合に限りあるグローバルIPを2つ消費する事になる。
 例えばWebアプリのようなアプライアンスで「IN限定」と割りきって利用できるならば問題にはならないかもしれないが、例えばメールサーバなど「サーバ→外部」の通信を行うサーバなどはそうも行かない。そうじゃなくても各サーバのアップデートやウィルスパターン更新には外部へのアクセスが必要になるだろう(※まあこれらはWSUSなどで別の手法を構築することもできるだろうが)。
 そんなわけで、「IN」の特徴と「OUT」の特徴を合わせた、よくあるFWのような「特定のIN」と「サーバから発信した通信の戻り」だけを受け付けるステートフルインスペクション的な挙動をする「INOUT」を作りたくなるのが、リソースに限りのある貧乏性のサ・ガと言えよう。海外のApplogicフォーラムとかも参考にしながらよーやく実現できた。

 大雑把に結論だけ言うと「iptablesを制御する」に尽きる。

 1.GUIで「IN」と適当なアプライアンスを置く。
 この辺は人によって様々だろうから適当に読み替えてください。また、この方法は単純に「IN」とアプライアンスが1:1で存在することを前提としてます。
 また、アプライアンスが元々「IN」として必要なIP設定などは済ませてください。

 2.「IN」をブランチ化して「INOUT」と名称変更。
 まあ名称はお好みで。最終的にはコレをテンプレ化して再利用したいところ。

 3.「INOUT」の[modify Boundary]からIntercface「in」を追加する。
 ただし上手くやればコレはいらないかも。元からあるインターフェース「out」を入力としても使えるようiptablesを書けば済む話かもしれない。が、見た目わかりやすいのでこうします。
 またコレと並行してアプライアンス側の「net」を前後反転させとくとわかりやすいですが、そこは好みの問題かもしれないです。

 4.上記「in」とアプライアンスの「net」を接続。
 これでデフォゲが「INOUT」に向いてるはず。

 5.アプリ起動。INOUTにCLIログイン。
 ここから先は起動したINOUT上で制御します。

 6./appliance/iptables-fwrules.shを編集。
 起動したINOUTの「/appliance」には初期起動時のネットワーク制御に実行されるシェルが幾つか置かれています。その中でiptablesの設定を行っているのが「iptables-fwrules.sh」のようです。また「~fwrules~」に何らかのエラーが発生した場合に前の状態を復元するバックアップシェルとして「iptables-bkrules.sh」とゆーのもあるようです。
 iptables-fwrules.shの中身はシンプルにiptablesコマンドを実行するシェル。通常だとGUIのPropertyで設定したIPや許可設定を実現する設定が書かれてます(なので以降は標準的なIN設定が終わってることを前提とします)。
 ので、コレを書き換えます。ここからは更に細部化します。

 6-1.IP情報の取得
 まずシェルのアタマの方で自身のIPやらI/Fやらの名称を取得してるところがあります。これらを参考に(※ほぼコピペでイケる。一部別ファイルを参照する必要あり)、上記3で追加したインターフェース「in」のIPアドレス、I/F、MACアドレスなどを取得します。
 なおこの後「in」のIPのアドレスを「$IN2IP」、I/Fを「$IN2IF」、MACを「$I2HWADDR」とします。

 6-2.アプライアンスからの接続許可(※非必須)
 iptables -A INPUT -m state --state NEW -m tcp -p tcp -i $IN2IF -j ACCEPT
 とか書いて、$IN2IFからの新規接続許可を記述します。まあこれはアプライアンスからINOUTに何がしかの接続をするための設定なので、転送に限定したい場合は不要です。ただこの設定を行うことで、従来一般的なSSHクライアントからのアクセスができない「IN」(アプライアンスに転送されるため)に対し、「まずアプライアンスにSSHログイン→そこからSSHでINOUTに」とゆーマネができるようになります。
 なおプロトコルとかはお好きなモノを適当に。

 6-3.インターフェース「in」からの接続許可
 標準的な設定ならば普通の中→外を許可する
 iptables -A FORWARD -p tcp -i $INTIF  -s $INTIP -o $EXTIF -j ACCEPT
 があると思いますので、その下にinから来たものを外へ出すのを許可する
 iptables -A FORWARD -p all -i $IN2IF -o $EXTIF -j ACCEPT
 を追加します。

 6-4.静的NAT設定
 外部へ出る際のNAT設定を記述します。このあたりはむしろ「OUT」を作って参考にすると良いかも。
 iptables -t nat -A POSTROUTING -p all -o $EXTIF -j SNAT --to $EXTIP

 6-5.「hosts_allow」への小細工
 シェルの下の方にhosts_allow、hosts_denyの設定を行う箇所がありますが、hosts_allow設定の最後の「DROP」を行う記述の前に、$IN2IFからの許可設定…とゆーかスルーする「RETURN」設定を入れます。
 iptables -A hosts_allow -i $IN2IF   -j RETURN

 7.設定を保存したらアプリケーションを再起動する。
 このシェル実行すりゃ良いような気もするんですが、なぜかそれだと上手く行きません。アプリケーションごと再起動します。


 ここまででたぶんイケてるはず。入力側はGUIのプロパティで設定した内容を保持しつつ、アプライアンスのグローバル向けデフォgwとしてINOUTが使えてるはず。
 なおiptablesの強制書き換えはセキュリティ上の不備を生む可能性もあるので十分注意してください。上記のやり方で問題ないとは言いません(苦笑)。まーこーゆー情報を求めてる人ならばiptablesの制御は問題ないと思いますけどね。

 本音を言えばこれらiptablesの制御もApplogic上のGUI、CLIで行いたいところなのだがどうもマニュアルを見てもそーいった方法が見当たらない。
 サーバ側のApplogicの設定として今回の「/appliance」の他に「/etc/applogic」などがあり、GUIで行った設定を書き込んでる様子があるので、その辺を制御できれば今回のようなマネはしなくて済むと思うのだが。まだApplogic使い始めて日が浅いんでよくわからん。サポートはアテにならないし。他に良い方法をご存知の方はこちらに書きこんでいただけると助かります(苦笑)。
関連タグ:クラウド
2011-07-25 [技術]

 むむ?いくつか保持してるGmailアカのうち1つだけ空っぽのがありますよ?w
関連タグ:Googleクラウド
2011-02-28 [インターネット]