そこで、OpenStackをデプロイすることにしました

おそらくOpenStackについて聞いたことがあるでしょう。 くそ、はい、彼らは多かれ少なかれ関連するイベントで彼について話します。 OpenStackを支持するすべての人。 ファッショナブルな若者、すべてがすでにそこにある、オープンソース、私たちに参加してください。 そして、大量のマーケティングの弾丸を聞いて、あなたは決める：OpenStackをインストールする！



私はこの主題に関する特別な研究を行っていませんが、少なくともロシア語では、それについての否定的なレビューはそれほど多くないようです。 一見したところ、すべてが素晴らしく見えます。 よろしければ、私の個人的な憎悪の投稿をOpenStackに送信してください。

背景

2012年頃のOSSに関する会議でOpenStackについて学びました。 当時、私は大規模なクラスター（100台以上のマシン）を積極的に使用している会社で働いていましたが、仮想化、オーケストレーション（kickstarter + IBM CSM？）を使用せず、主にタスクのバッチ実行を行いました。 クラウドとは何か、なぜクラウドが必要なのかを完全に理解することはできませんでしたが、関心が生じました。 もちろん、すぐに新しいクールなものを展開したいという要望がありましたが、今はすべてがうまくいきます。



同じ年の少し後、すでにスタートアップの一部として、そのような機会が現れました。 クラスタリングと水平スケーリングを使用してプロジェクトを展開する必要がありましたが、環境を分離し、1台のマシンのリソースを複数のサービスと共有する必要がありました-予算はまだゴムではありません。



一般に、2012年にOpenStackを展開しました。当時はEssexでしたが、プロジェクトを開始し、2014年までこのようなクラウドインフラストラクチャを使用していました。Grizzlyがリリースされるまでです。 彼をさらにサポートする力と欲求はなく、OpenStackは恥ずかしそうに酔っていました。



むかしむかし、何を探すべきかについてのコメントを付けて、それを正しく置く方法に関する記事を書くことさえ考えました。 しかし、あなたは知っている、私は私の心を変えました。 まったく良くしないでください。 混乱しないでください。 ほとんどの抄録は古くなっている可能性があり、私がどんな人であるかについてのコメントを書き、何も理解していませんが、全体的に状況が劇的に変わったとは思いません。



それでは、Openstackについて私が好きではないものから始めましょう。

彼は複雑すぎる

それさえも。 彼、*****、 MONSTERY 。 いいえ、自分で見てください。







むかしむかし、エセックスを設置したとき、すべてが比較的シンプルで明確でした。 Keystone（承認サービス）、Glance（画像保存サービス）、Nova（ハイパーバイザー管理サービス）。 さらに、まだHorizo​​n（ダッシュボード）があり、小さくてあまり依存していませんでした。 システムの各ノードは、ほぼ数十の補助デーモンに囲まれています。 しばらくすると、コントローラーノードを見るのが怖くなります。







そのため、仮想クラスターが20台のサーバーに近づくと、何らかの理由でコントローラーノードが恥知らずにスローダウンし始めました。 まあ、より正確に理解できますが、なぜIDサービスがプロセッサを100％読み込んだのかはわかりませんか？



複雑さから、次の欠点が生じます。

彼は混乱しています

OpenStackのアーキテクチャは非常に断片化されています。 非常に多くの「可動部品」があり、それらの間の関係は常に絶対に明確ではありません。 何か壊れていますか？ さて、何かが壊れた場所とその理由を理解してください。 OpenStack Foundationは、OpenStackのサイトのメインページでも、2,000万行を超えるコードを誇っているようです。 したがって、 このNIFIGAは尊厳ではありません 。



ほとんどのコードはPythonで書かれています。 ありがとう、OpenStack、あなたのおかげで、私はPythonとそれに関連するすべてのものを嫌っていました。 おそらく今ではドキュメントの方が優れていますが、実際には存在していませんでした。 ロジックは1つのデーモンで開始される可能性が高く、その後、RabbitMQを介したクエリの助けを借りて、まったく異なるマシンで、さらには別のマシンで実行されます。 言うまでもなく、OpenStack用の独自の拡張機能を作成するのは簡単ではありません。 それが単なる小さなハックである場合、それは新しい機能を備えた本格的なプラグインである場合、別のことです。 絶対にできない5行のコード。



そこで何が起こっているのかを理解するために内部を取得する必要がある場合...







事実、OpenStackはOSSとして一種のunix-wayを目指しています。 すなわち 内部では、これらの巨大なサービスはすべて、独自のロジックに従って数十から数百のUNIXユーティリティを実際にプルします。 ドキュメンテーションでは、少なくとも以前は、すべてが悪かった。 ホストに追加するiptablesルールとその理由を正確に教えてください。 私たちには、すべてを単独で実行し、ユーザーの介入を必要としない、非常にクールなアプリケーションがあります。 独自のルールを追加したいですか？ 幸運なことに、ソースコードは公開されています。



著者によって提案されたシナリオに多少適合しますが、すべては多かれ少なかれ大丈夫です。 あなたが側に一歩を踏み出す必要がある場合、困難を期待してください。 たくさんの忍耐、忍耐、たぶん、タスクに直接関係しないいくつかの問題、たとえば、RabbitMQがどのように機能するか、他に何が必要かを勉強する必要がありますか？



これにより、次の問題が発生します。

彼は信頼できない

システムが複雑になるほど、システムの信頼性は低くなります。 しかし、どうやらこの真実は万人向けではありません。 アンダーグラウンドノックのソースを検索する準備を整え、 正しいシーケンスでデーモンを起動し、たくさんのgoogleを実行してログを読み、ソースファイルを掘り下げてください。



私の意見では、いくつかの決定は単純に物議を醸しています。 iptablesを介してエミュレートされる仮想IPアドレスのメタデータサービス？ ほんと？ IP仮想マシンの発行に関するdnsmasqの非常に「信頼できる」作業。 数千人。



そしてこれは、...

彼は大きくなっています

私が言ったように、私たちがちょうどそれを使い始めたとき、いくつかの問題がすでにそこにあったけれども、多くのサービスがありませんでした。 しかし、サービスのリリースごとに、それはさらに多くなります。



たとえば、現在のサービスのリストを見てください。各サービスは、マシンにさらにいくつかのデーモンを追加します。

• アイデンティティサービス（キーストーン）
• イメージサービス（一目）
• 計算サービス（nova）
• ネットワーキングサービス（中性子）
• ダッシュボード（水平線）
• ブロックストレージサービス（cinder）
• ベアメタルサービス（ironic）
• コンテナインフラストラクチャ管理サービス（マグナム）
• データベースサービス（trove）
• DNSサービス（指定）
• キーマネージャーサービス（バービカン）
• メッセージングサービス（zaqar）
• オブジェクトストレージサービス（Swift）
• オーケストレーションサービス（熱）
• 共有ファイルシステムサービス（マニラ）
• テレメトリアラームサービス（aodh）
• テレメトリーデータ収集サービス（ceilometer）

はい、正式にすべてのサービスを完全にインストールする必要はありません。 ただし、メインサービスに含まれていない些細なことをインフラストラクチャに簡単かつ簡単に追加できるとは思わないでください。



たとえば、エセックスの時代には、新しい仮想マシンに関するエントリをDNSサービスに追加する簡単な方法はありませんでした。 手-お願いします。 フック？ いいえ、聞いていません。 指定の誕生を待たなかった。



そして、あなたは何を知っていますか？

彼は故障する

リリースからリリースへ。 すなわち さて、あなたは最終的に夢のインフラストラクチャを切り裂き、すべてが何らかの形で期待どおりに機能しますが、1つの小さな詳細が欠落しています。 そして、新しいリリースではそうです。 まあ、少なくともリリースノート。



OK Google、OpenStackを更新しましょう。 そして、あなたが喜んで使っていた機能が切り取られたことがわかりました。 まあだから。 まあ、彼はいし、一般的に、私たちは、正直に、正直に、より良くやるでしょう。 次のリリース。 たぶん。 それまでの間、ここでは簡単になりましたが、うまくいきました！ まあ、あなたのケースにないものは気にしませんが、それは動作します！



私たちの場合、それは機能的なネットワークでした。 ネットワークは一般に問題であり、OpenStackで最も苦痛をもたらします。 一般的に、このアプリケーションはインターネットからのトラフィックを消費しますが、非常に集中的に使用することもあります。 もちろん、これは完全に標準的な要件ではありませんが、仮想マシンが独自のホストをルーターとして使用し、ホスト自体が直接プロバイダーにトラフィックを送信する場合に最適なオプションです。 そして、それはエセックスで行うことができます。 そしてそれはどういうわけかうまくいった。



そして、次のリリースでは、OpenStackの担当者は素晴らしいと判断しました。ネットワーク機能を別のモジュール（将来のNeutron）にカットし、仮想ネットワーク上の1つのルーターのような単純なものを実装します。 すなわち クラスター全体のすべてのトラフィックをネットワークの単一ノードに通す必要があり、それがボトルネックになります。



そのため、OpenStackは本当に機能するものなので、触れないでください。 そこに小さな手を刺そうとさえしないでください、n ** p。 万が一に備えてホストを再起動しない方が良いでしょう。そうしないと、再び起動しませんか？ 更新は緊急、神経、憎悪です。

彼は生々している

そして、機能、たとえばゾーンへの分割が必要なとき、あなたはとても素晴らしい気持ちを感じます。 さて、大きなネジのあるマシン、SSD、ビデオカードがあります。クラスターをゾーンに分割して、必要なリソースを持つマシンに仮想マシンが分類されるようにします。 さて、OK、ドックを読んで、アベイラビリティーゾーンが適しているようです。 設定、有効化。 そして何もない。 ドックは、すべてがすべきであると言っていますが、実際には何もありません。 私たちはコードに登ります。







実装されます。 次のリリース。 たぶん。 さて、あなたはポイントを得る。 前の段落を参照してください。

利点はありますか、結論は何ですか？

私にとって、結論は簡単です。 OpenStackのバニラバージョンは避けるのが最善です。 ベンダーバージョンや、ターンキーインストールを販売するオフィスでの状況はわかりませんが、私にとっては、これは「無料クラウド」のイデオロギーにいくらか矛盾しています。 別のソースでのみ、ベンダーのロックインを再度取得します。



Vanilla OpenStackで運試しをしてみませんか？ いいえ、まあ、一般にお願いします。 多くのプラグインがあり、コミュニティは大きく、マーケティングの弾丸は一般に屋根よりも高くなっています。 一般的に頑張ってください。 ただし、小規模および中規模のインストールの場合は、お勧めしません。



私の意見では、OpenStackの主な問題の1つは、完全に正しいアーキテクチャメッセージではないことに起因しています。 エンドユーザーだけのために努力して、結果を複雑にしすぎました。 フックのような単純で平凡なものでさえイベントに配信されなかったため、誰もが彼のニーズに応じて悪夢に変わりました。 そして、これは多くのことの実装をどのように簡素化しますか...



一般に、OpenStackとの1年半の闘争の後、私たちはそれを放棄し、別のクラウドに切り替えました。 インフラストラクチャの管理は簡単で楽しく、バージョンの更新はapt dist-upgradeと同じくらい簡単です。



これはどのようなクラウドで、なぜOpenStackよりも便利なのか、次の記事で説明します。 （ネタバレ：これはOpenNebulaです）。