とてもツマらない障害対応のメモとなります。 が、英語圏には多少の情報はあったけど日本語になかったので、書き留めておきます。 障害内容 ある日、突然、OpenStack Grizzlyの管理画面からインスタンス作成などの操作が全てできなくなりました。 既存のインスタンスには特に影響なく稼働していました。 原因 動作的には、認証システムであるKeystoneと、それ以外の全てのコンポーネントとの認証が失敗することが原因となりました。 nova list や glance image-list などが Unauthorized 401 になる状態です。 根本的な原因は、Keystone管理のSSL証明書の期限が切れたことによるものでした。 調査内容 初めはトークンデータが溢れて記録できなくなったのかと思いましたが、keystone-manage token-flush を実行しても特に解決できず

Horizonにログインすると、利用状況の概要がそれなりに表示されますが、多くのユーザが利用しだすとそれだけでは物足りなくなってきます。 そこで、ユーザ別利用状況や人気OSイメージを表示するスクリプトを書いてみました。 Bashスクリプト 長いのでGistにあげました。 openstack-vm-summary.sh 使い方 /usr/local/bin/ にでも置いて、 jq コマンドを落としてきて（やり方は書いてあります）、 TENANT_NAME を編集して、 root権限で実行します。 表示内容はこんな感じです。 ======================================= VM Summary Report ======================================= ==================== Project Info ----

OpenStackのVMは、一度起動してしまえば、起動したユーザが削除されても動き続けます。 そんな取り遺されたVMのリストを表示するスクリプトを公開しておきます。 Bashスクリプト 長いのでGistにあげました。 openstack-retire-users-vm-list.sh 使い方 /usr/local/bin/ にでも置いて、 jq コマンドを落としてきて（やり方は書いてあります）、 TENANT_NAME を編集して、 root権限で実行します。 表示内容はこんな感じです。 ======================================= Retire User's VM Report ======================================= USER_ID : VM_NAME ( VM_ID ) ---------------------

OpenStackの構築についてひと通り書いたので、運用面についても色々と綴っていきたいと思います。 手始めに各種制限事項の確認と設定例です。 セキュリティ セキュリティといっても小難しいものではなく、外部からインスタンスへのINPUT接続（NetworkNodeでのFORWARD）を通す条件の設定です。設定は単に iptables で実現されているので、NetworkNodeで iptables -L -v -n を打てば確認できます。 OUTPUTや、インスタンス同士の接続は制限なく全てスルーになっています。 設定例としてこんな感じ。 最初はPing, SSH, HTTP だけでも通しておけばOK。 プロジェクトごとに設定し、必要があれば default 以外も作っておきます。 # usage: nova secgroup-add-rule <secgroup> <ip-proto>

(10)まできてようやく基本手順が終わろうとしています。 最後はComputeNodeを単体で追加する手順です。多少のハマりどころはありますが、大雑把に言えばControllerNode構築手順から、ComputeNode関連のみ抜き出しただけなのでサクサク書いていきます。 Compute Nodeインストール こちらの基本設定は完了しているものとします。 OpenStack Grizzly構築 on Wheezy (1) 全ホスト共通 事前準備 | 外道父の匠 ComputeNodeパッケージを入れます。 NovaComputeがエラーを吐くのでnova-conductorが必要です。

ひととおりコンポーネントの設定が終わったところで、ネットワークの作成を行います。 ここは組みたい構成によってちょこちょこ内容が変わるので、１つの参考にしていただけると。 構成について 絵は面倒くさいので箇条書きで説明します。 adminプロジェクトが全体で１つのルータを持ちます adminプロジェクトは外部ネットワークを持ち、ルータのExternalG/Wとします adminプロジェクトは内部ネットワークを持ち、ルータに紐付けます 一般プロジェクトは内部ネットワークを持ち、同じルータに紐付けます 外部ネットワークのG/WアドレスをControllerNodeに割り当て、内部ネットワークへのルーティングをルータのG/Wに送ることで、Linux Network Namespaceを介さず内外を疎通します 今回の構成・運用で重要なポイントは、いわゆるFloatingIPはVMに割り当てないという

設定の最後に、痒いところも掻いておきます。 設定記事が完了するまでに (8) ってなんというシステムなんでしょう！ Ceilometer 悲しいことに、まだ動かないとパッケージの説明に書いてあり、本当に動かないですが、気持ち設定だけ編集しておきます・・・ /etc/ceilometer/ceilometer.conf log_dir=/var/log/ceilometer log_file=ceilometer.log rabbit_host=10.1.26.11 rabbit_port=5672 rabbit_userid=openstack rabbit_password=Rabbitのパスワード rabbit_virtual_host=/openstack [keystone_authtoken] auth_uri = http://10.1.26.11:5000/v2.0/ aut

Cinderもそれなりにイイ子なのですが、ちょっと原因を人に伝えるのが苦手だったり、よくlibvirtdクンと喧嘩したりするので、ハマらずイケるといいですね！ ここではあえて修羅道であるCeph連携の手順を紹介しています。 パッケージ ここまでで既に入っているはずですが、念のため見逃しそうな関連パッケージをおさらい。 sysfsutils がないと systool is not installed というエラーが出ます

おそらく一番手がかからない子、Glanceくんの設定です。 今回はCephに保存していますが、Swiftで試した時も素直に動いてくれた、OpenStackの良心とはこのコのことです！ Cephの準備 pool作成 Glanceは所詮コンポーネント名なので、役割重視で名前は images です。

次回からリネームカードによりNeutronに名前が変わるQuantumさんの設定になります。 Quantumの設定はOpen vSwitchも相まってハマりやすいため、１つ１つ丁寧に、意味を調べてから反映して確かめましょう。そうしましょう。 sudoers修正 sudoの実行エラーログを見ると、quantumさんが実行できずに苦しんでいるコマンドがあるのがわかります。まぁ色々事情はあるでしょうが、とりあえず寛容に通してあげておくとします。 これらを追記して、強制保存してあげてください。 /etc/sudoers.d/quantum_sudoers quantum ALL = (root) NOPASSWD: /sbin/ip netns * quantum ALL = (root) NOPASSWD: /sbin/ip -o netns * quantum ALL = (root) NOP

編集する部分、確認すべき部分のみ記載します。 ControllerNodeと、ComputeNodeでは my_ip だけが相違点になります。 /etc/nova/nova.conf [DEFAULT] sql_connection = mysql://nova-common:MySQLのパスワード@10.1.26.11:3306/novadb enabled_apis = ec2,osapi_compute,metadata my_ip = 10.1.26.11 # # データディレクトリのパス # state_path=/data/nova instances_path = $state_path/instances base_dir_name = _base # # スケジューラ # scheduler_driver=nova.scheduler.multi.MultiSchedul

パッケージで丸ごとControllerNodeのインストール、そしてKeystone少々までいきます。 パッケージに質問を80個近く投げられて最初はよくわかんないですが、どうせ何かに失敗して丸ごと構築しなおしたりして、慣れて何も見ずに入力できるようになることうけあいです。 dbconfig-common コンポーネントが多いので使います。 apt-get install dbconfig-common dpkg-reconfigure dbconfig-common Keep "administrative" database passwords? ＜いいえ＞ Will this server be used to access remote databases? ＜はい＞

それでは続いて、皆大好き・恐怖のOpen vSwitchの設定になります。 初見は、カザーブの東にお散歩に行ったら突然エンカウントしたグリズリー級のわけわかめなシステムですが、慣れたら大丈夫っていうか、自分にとっての正解を見つけてしまえばあとは元気にスルーするだけなので頑張りどころだったりします。 事故事例 Open vSwitchの設定は、NICの数やQuantumの設定（ブリッジマッピングなど）によって正解は変わってくるのですが、ミスった時はだいたいこのような現象になります。 ovs-vsctlコマンドで設定したらプライベートネットワークすら繋がらなくなった VMに接続できない ホスト間をまたいだVM同士の接続ができない VMがDHCPアドレスを取得できない（参考：OpenStackのDHCP問題まとめ） GREパケットでフラッディングが起きる（参考：OpenStack Open vS

今更感が漂う内容になりますが、Havanaが参上する前に記しておきます。 Folsomから変わっている部分は多いですが、流れは似ているのでザックザクと書いていきます。まずは、その他色々の事前準備からです。 環境について HostOSはDebianのWheezyです。 ControllerNode＋NetworkNode で１台（分離していません）。 ComputeNode で２台の合計３台で構築しています。 また、Networkの冗長化やLbaaSは手がけていません。 他、OpenStackの細かいところは都度書いていきますが、大きな特殊構成は２つです。 Glance＋Ceph, Cinder＋Ceph Keystone＋LDAP これについては既に記事にしてあるので、リンクをはって済ませていきます。 OS設定 ulimit ulimitで詰まることはおそらくないでしょうが、これでひっかか

7/23（火）に、弊社カフェにてgloopsさんと勉強会を開催しました。 今回、私はOpenStackについて、こんな風に使ってますよ～という内容で発表させて頂きました。その資料がこちらになります。 補足 就活 冒頭で、『就活に役に立たない』とぶっ込んでしまいましたが、 採用面接の際に、「OpenStackを構築したことがあります！」のコメントで うん、コイツは厳しい道をやり遂げる根性はあるな！とポイントアップして 採用に至った例を聞いてしまいました。 なので、皆さん、もっとOpenStackを触って情報を公開して自慢していけばよいと思います！ 社内で既に使ってもらっていますが、ほぼ不満なくいっぱい利用してもらえています。 長く使う開発環境としてはもちろんですが、 ちょっと調べたい時に、起動して即ポイできるのも想像以上に魅力的なようです。 格好つけて多くのOSを用意していますが、 弊社では

調べる気になった事の発端は、Cinder＋Cephのボリュームに対してMySQLのtpccベンチマークを取ってみた時に、vCPU=1 でVM内では CPU : 100% なのに、KVMプロセスのCPUが 300% を超えているのを見つけたことでした。 KVMは仮想環境なので当然オーバーヘッドが存在するのは覚悟済みですが、想像以上にホストOS上でCPUを食っていたために、良い子の私は地道に調べ始めるのでした。 検証環境 CPUとメモリ ホストOSのcpuinfoの表示ですが Intel(R) Xeon(R) CPU E5-2630L 0 @ 2.00GHz VMだとこう Intel Xeon E312xx (Sandy Bridge) まぁほどほどに最近の、お値打ち価格になってきた低電力版なナイスCPUです。 VMへは 1～4vCPU 割り当てて検証しています。 VMに割り当てたメモリは全て

コンポーネント毎に設置されている policy.json ですが、デフォルト設定だけでも多いのに、隠れ設定もいっぱいあるため把握するのが非常に面倒くさいです。 が、デフォだと他人が作成したVMを勝手に削除したり色々できてしまうので、 グッと我慢して、隠れ設定のページを見つけたり、他人のVMをイジれないようにしました。 Nova 目的は、別ユーザが作成したVMを削除したり、コンソール覗いたり、Volumeを弄ったり、スナップショット取ったりできないようにすることです。参考にしたページはこちら Re: [rhos-list] Control Access to instance termination /etc/nova/policy.json "admin_or_user": "is_admin:True or user_id:%(user_id)s", "compute:attach_vo

VM作成時のホスト決定のためのSchedulerにおいて、デフォルトで利用されるFilterの１つにRamFilterがあります。 これはホストの残りメモリ容量にたいして何倍まで許容するかというフィルタらしいですが、デフォ値が 1.5 なので計算内容や状況によっては SWAP / OOM Killer 逝きになる可能性があるのかな、と気になったので良い子の私は、どのようなメモリ値を使ってどのように計算しているのか確認してみることにしました。 リンク Schedulerについてはこの２箇所を見ておけば大体よさそうです。 Chapter 10. Scheduling – OpenStack Compute Administration Guide – Grizzly, 2013.1 OSSはアルミニウムの翼で飛ぶ: nova-scheduler in OpenStack Grizzly デフォ

先日、１つの問題に１週間以上ハマって悶絶するも、絞りだすような勘と数えきれない再構築によって、命からがら解決することができました。 その問題とは、２台目以降のホストであるComputeNodeのVMがDHCPからアドレスを取得できない というもので、これについて多くの情報を仕入れたのでまとめておきます。 DHCPからIPアドレスが取得できない現象 ControllerNode１台で構築し（NetworkNodeは分けていない）、VMを作成する分には問題なくDHCPからアドレスがリースされるのに、ComputeNode単体ホストで作ったVMはアドレスを取得できない、という問題でした。 その時どうなるかというと、VMからQuantumネットワークのDHCPサーバにリクエストは飛ぶものの、レスポンスが返せずにレスポンスパケットが永久に垂れ流され続ける状態になりました。 しかも、Quantumネッ