スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

[雲] openstackその1

インストールやデプロイ、設定が意外に難しい
(というか、結構つまらんところでコケる)という印象。
自分用にメモを残しておこうと思う。

少しずつ太らせていこうとは思うが、出まわってる情報
の後追いなので他の人にとってあまり有益なものは
ないような気はする。


■情報源

●全体
 openstack.org
 日本openstackユーザ会
 API reference
 slideshare
 RHEL OpenStack Platform

●デプロイ
 stackforge/packstack
 RDO
 TripleO (OpenStack On OpenStack)
 Chef for Openstack
 FUEL(Mirantis)
 DevStack

●ソース
 サイズは、android版gitでgit cloneしたときのおおよそのサイズ。

 nova (250MB)
 neutron (65MB)
 horizon (120MB)
 cinder (44MB)
 glance (22MB)
 keystone (30MB)



■nova

●プロセス
・窓口:nova-api
・DB負荷の軽減:nova-conductor
・VM割当:nova-scheduler
・証明書管理:nova-cert
・nova-compute
・流れ:nova-api⇒nova-scheduler⇒nova-compute

●メタデータ
・metadataサーバか、コンフィグドライブ

・コンフィグドライブとは:VM起動時に接続される特別なディスク領域にメタデータ
 (VMの管理情報。たとえばネットワーク設定など)を書くように設定し、VMが
 そのディスク(ドライブ)をマウントすることでVMがメタデータを取得ようにする仕組み。
・コンフィグドライブは、ISO9660かVFATのファイルシステムであり、
 ハイパーバイザーがlibvirt、hyper-v、vmwareならば使える。
 libvirtで使う場合の例だと、genisoimageというプログラムが必要だったり、事前準備が要る。
 VMイメージにcloud-initが入っていれば、メタデータの読み取りにconfig driveは使える
・コンフィグドライブを使うかどうか、VM起動時にnova bootのオプションで指定可能。
 VMからはラベルを使ってコンフィグドライブのディスクにアクセスできる。
 ISO9660ファイルシステムというところからわかるようにCD-ROMとしてのマウントも可能。
・コンフィグドライブにあるメタデータ(json)は、EC2メタデータとOpenStackメタデータの
 2つの形式があるようだが前者は今後なくなるかもしれないので後者で書くのが吉

●マイグレ
 基本は、コールドマイグレ、ライブマイグレ、ブロックマイグレの3つ。
 boot from volumeなVMだと、ボリュームマイグレもパターンの1つだが
 これはnovaというよりcinderが主管。
・コールドマイグレ
 文字通り、止まっているVMを他のホストに移す。移動手段は、rsync。
・ライブマイグレ
 文字通り、動いているVMを他のホストに移す。移動手段は、libvirtdによるメモリ転送。
 マイグレ元・先で共有しているディスクの上でVMのデータも共有しておくこと
・ブロックマイグレ
 ライブマイグレに近い。違いは、共有ディスクが要らない点。
 なぜなら、メモリだけでなくディスクも転送してしまうから。

・boot from volume
 VMにディスク(ボリューム)を追加ディスクとしてアタッチ、
 という使い方ではなくて、ボリュームから直接OS起動してしまう。
 ボリュームをbootableなディスクとして使う。
・ボリュームマイグレ
 bootableなボリュームを別ロケに移動させる。
 スナップショットなし、デタッチされたボリュームはマイグレできる

・スケジューリング:VMをどの物理ホストに割り当てるか
 ⇒ Region、Available Zone、ホストアグリゲート、等でマシンのグルーピング
・SPICE:KVMのremote desktop protocol
・azはhost-aggregateをベースに実装されている?

●メッセージ
・コンポーネント間で非同期に通信の送受信をするために、間に
 メッセージングキューを用意する。
・AMQPでのメッセージングになっていることが多い。
 RabbitMQなどを使用。
 Advanced Message Queueing Protocolの略。
 なお、rabbitはErlangという言語で実装されているので、こいつを
 動かせるようなところじゃないとrabbit mqを動かせない。

・メッセージ:アプリケーションから渡される通信内容を包んだもの、情報のかたまり。
 通信の中身(封筒の中の手紙に相当)だけでなく、封筒に記載された住所などにあたる
 routing keyなどの管理用情報、配送用情報なども含めてメッセージと呼んでいる。
 routing keyやpriority, expireなどの情報はヘッダにある。
・ブローカー:AMQPをしゃべるクライアントの接続先。AMQPサーバをメッセージブローカーとか呼んだりするらしい

・ブローカを理解するための基本概念:exchange, binding, queue
・Exchange:交換局、と訳せばいいのか?メッセージを送信元から受け取ってキューに流す人
・Binding:exchangeとキューを対応させる表みたいなものか
・Queue:送信先にメッセージを流す人。FIFOで送信。送信元はこいつを購読して状態をみている

・メッセージ配送の種類:direct, fanout, topic → exchangeのtype
・direct:メッセージのrouting keyと、binding keyが一致したら該当キューに流す
・fanout:ブロードキャストみたいにexchangeに紐づく(bindされている)
 全てのキューに同じメッセージをいっせいに流す
・topic:メッセージのrouting keyを階層区切りにして部分一致でもキューに流す

・キュー、メッセージの永続化:クライアント側(送信元)から、メッセージを送る際に、
 キューを作るわけだが、その際にブローカを再起動してもキュー内のメッセージが
 永続化するようなフラグをつけておけば、そのような振る舞いにもできる。
・RabbitMQの使用DBは、mnesia。分散DBMSらしい。
 rabbitmq-serverから参照する。

・メッセージングが頻繁な場合、たとえばOpenStackでいえば
 VMの数が多いとか、特定のリソースが過剰にある場合を想定すると
 このMQ部分が原因でそれ以上スケールできない台数というような
 境目が出てくる。設計どおりにいくかどうか要注意。

・MQのところの冗長化(可用性および負荷分散、性能)は
 考慮しないといけないのでは。。

●ボリューム
・スキャンでやりたいこと
 ⇒ 「ls /sys/class/scsi_host/host」でSCSIコントローラのホストが分かる
   「tee -a /sys/class/scsi_host/ホスト/scan - - - 」でrescan



■cinder
・マルチバックエンド

・apiで外から依頼を受けて、rpcapiで他に流す
 → cinder/volume/rpcapi.pyのVolumeAPIクラスを読む
 → ここの各メソッドの書き方は特徴的。
   oslo.messagingのoslo/messaging/rpc/client.pyにいるRPCClientを
   取得して、prepareにてcall contextを上書きしてから
   castまたはcallのメソッドを実行する。
   castはリクエスト出したらすぐにリターンが返るので非同期で動ける。
   callはリクエスト出したらrpcサーバ側から返答あるまで待つ同期型。
 → transport:callやcastの先では、このクラスに登録したドライバ
    (たとえばAMQPドライバ。oslo/messaging/_drivers/amqpdriver.py)
     のsendメソッドやsend_notificationメソッドが実行される
   target:メッセージ送信先
   serializer:
   context:

・quotaは一度リソースをリザーブして、実際に資源を作ったらコミット。
 なんらかのエラーなどで失敗したらロールバック。
 → 何か開放漏れがないか?排他で問題ないか?のような確認はしておく

・novaAZとstorageAZ。cinder_cross_az_attachの真偽値をどちらにするか

・cinder-volumeのドライバは、ストレージ製品によりいろいろ変更できる。
 呼ばれた末端での操作は、当然製品に強く依存する。
 ライセンスによる機能制限チェックもあったりするかもしれない。
 → その他、不要なリソースが残ったり、リークがあったりしないか?確認




●メモ
openstack-01.7z
・GET /v2/images?name=hogehoge&status=mogeのように絞込みを活用
・CLIで--debugを指定すると実行しているHTTPリクエストが見れるのでcurlなどで実行するときの参考にできる
・curl --verboseでHTTPヘッダが出せるので活用すべし
・解析時、APIのレスポンスに付与されるrequest idは重要な手がかり。該当するidを追っていく。
maas →最新は1.7.1
 → 1.4とか1.5のころよりだいぶ進歩している。インストール方法はあまり変わらないが
   boot imageの取得はインターネット上から取得だったのが、ローカルにもってきて
   ミラーを作る仕組みができているし、かなり便利になっている。



●その他あるある?
システムに組み込んじゃった後だとUIで隠蔽されていて起きないかもだが、
手元にあって自由にいじれるところだと、REST APIでちまちまやったときに
くだらないところでミスしたりする。

keystone v3でトークン取得時のスコープ(ドメインまたはプロジェクト)を間違える(40Xが返ってくる)
・トークン取得時のドメイン、プロジェクトと、そのときのトークンを使った操作で対象になっているドメイン、プロジェクトが異なっている(contextが違う系の怒られ方)
glanceでcontainer_formatとdisk_formatを指定し忘れてイメージデータのuploadでコケる(50Xが返ってくる)(preconditionに書いてあるのに。。)
・使いたいAPIのバージョンと、環境変数かオプションで設定しているAPIのバージョンが違っていて、実行したいAPIがない(指定しなさいよ)
・HTTPリクエストで指定すべきヘッダが抜けている、間違えている、もしくは手打ちcurlでtypoした(もちつけ)
・エンドポイント間違い(たいがいポート指定ミス)
・途中経路にはさまっているものをすっかり忘れてリクエストを出す(openstackのログだけ見てても何が起きたか分からん)
・セキュリティグループの設定もれ(デフォのまま)や設定ミスで、必要な通信ができない、もしくは特定方向しか成功しない(もちつけ)
・qemu-img createでqcow2フォーマットで作成するときにqcow2のバージョン指定(compat)間違いによりnova bootできない(どこで動かすのか考えるべき)
・マイグレできると思ったらcpuの互換性がないといわれたでござる(libvirtを調べてちょ)
・nova bootしたものの何かでコケてno valid host was found(どこが原因なのかわかりにくい。。)
・リソース不足や使用リソースの異常(イメージのqcow2のバージョンが変とか)でno valid host
・ディスク100%(気づけよ)
・tokenの期限切れ
・排他処理でブロックされるために性能問題が出やすい場所は?
・非同期でapiからすぐに応答返すのか、それとも同期処理になり待ちが出るのか?の差


関連記事
スポンサーサイト

コメントの投稿

非公開コメント

プロフィール

kr2

Author:kr2
ネコと音楽が好き。
CD紹介、技術ネタ
などの雑記帳。

カレンダー
10 | 2017/11 | 12
- - - 1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 - -
月別アーカイブ
カテゴリー
ブログ内検索
RSSフィード
最近の記事
最近のコメント
最近のトラックバック
リンク
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。