サービスプロバイダー向けOpenStackについて

ポール・ロバーズによる投稿



アイスランドから東京までのサービスプロバイダー（サービス/通信/マネージドサービスのプロバイダー）で働いた最後のいくつかの場所では、無条件のリーダー（「800ポンドゴリラ」）-パブリッククラウド-魂。 しばらくの間、彼らは皆「死んでいるふり」をしようとしましたが、「ゴリラ」はすべて同じで、彼女は彼らの方向に走り続けました。 旅行中、私は一つのことについて疑いがありませんでした。サービスプロバイダーは、何かを根本的に変える必要があることを認めなければなりません。 彼らはどうやってこれに来ることができますか？







撮影者 ：Ryan Poplin



今日の私の仕事の一部は、クライアントを訪問して、OpenStackプラットフォームとは何か、その機能は何か、インフラストラクチャと統合できるかどうかを伝えることです。 1つ明らかなことがあります。パブリッククラウドベンダーとの戦いに参加するには、サービスプロバイダーがクラウドサービスの提供内容を修正および改善し、ソフトウェア定義テクノロジーと自動化に焦点を移す必要があります。



パブリッククラウドのエコシステムを見ると、プラットフォームの最も深刻な競争上の利点の1つは自動化機能であることがわかります。 残念ながら、今日の多くのサービスプロバイダーは古いハードウェアおよびソフトウェアインフラストラクチャを使用しています。 私は最近、時代遅れのインフラストラクチャで作業しているいくつかのサービスプロバイダーと会いました。残念なことに、自動化はエンジニアが座席で回転できる速度に基づいていると考えています。 今日の市場で大規模なパブリッククラウドと競合するため、サービスプロバイダーは適切なアーキテクチャ基盤を取り戻すために、OpenStackなどのインフラストラクチャを模索しています。

OpenStackでの作業に自分でアプローチする

OpenStackに基づいて独自のクラウドを構築する非常に洗練されたサービスプロバイダーに時々出くわしました。 彼らとの会話はおよそ次のとおりでした。



私：OpenStackプラットフォームで作業することは素晴らしいことです。 彼女と一緒に物事はどうですか？



彼ら：これは悪夢です！ すべてをセットアップする方法を見つけるのに数週間を費やし、エンジニアはIRCチャットとフォーラムで回答を探す必要があります！



私：すごい！



私はあなたの多くがあなたの家の所有者またはテナントであると信じています。 あなたのほとんどは機械エンジニアやデザイナーではなく、家の中のすべてがどのように組み立てられ、機能するのかわからないでしょう。 これは私たちには必要ありません。



OpenStackについては、ここで家との類似性を引き出すことができます。 OpenStackは、最も経験豊富なインフラテクニカルサポートエンジニアでさえも戦っている洗練されたAPIを介してリンクされている多くの包括的なオープンソースプロジェクトに基づいています。 財政的観点から、初期段階でこの経路を選択すると、未達成のビジネス目標と期限を守れないため、収入に深刻な影響を与える可能性があります。 日曜大工アプローチでは、多くの人がOpenStackで作業を開始し、原則として失敗します。これにより、非常に不快な「後味」が残ります。



サービスプロバイダーの主なビジネス目標は、顧客アプリケーションの信頼できるホスティングの設計と提供を支援することです。 OpenStackを使用する際の成功の鍵は、必要なすべてのコードフラグメントを収集し、ビジネスの運営に必要なエンタープライズレベルのサポートをサービスプロバイダーに提供するベンダーを引き付けることです。 OpenStackのテクニカルサポートとパッケージングを信頼できるベンダーに委託してください。

OpenStackを提供するもの

今日、OpenStackは、さまざまなソフトウェアインターフェイスを1つの共通インフラストラクチャまたはAPIに抽象化および結合することにより、顧客が異種技術インフラストラクチャを簡素化できるフレームワークを提供します。 最も重要なことは、データセンター（DPC）の効率を高めることです。

ネットワークの観点から、OpenStackは現在、F5 Big-IP、Cisco Nexus、Citrix Netscaler、Aristaスイッチなどの有名なデバイスとの統合方法を提供しています（より多くのデバイスとの統合が期待されています）。 ストレージに関しては、 EMC、NetApp、Coraid、NexentaのすべてがOpenStackに統合されています。 ハイパーバイザーの場合、VMWare、KVM、Xen、HyperVなどのオプションから選択できます。 サービスプロバイダーは、インフラストラクチャから完全に独立したデータセンターアプローチを使用して、OpenStackがすべての複雑な問題を解決できるようにすることができます。







アトランタでのOpenStack Summitでのユーザー調査によると 、OpenStackを使用する第一のビジネスインセンティブは、単一のベンダープラットフォームに縛られないようにすることです。 サービスプロバイダーは、ハードウェアとソフトウェア（ソフトウェア）の生産において、緊急の問題を解決する際に互いに指を差し向けないパートナーとの協力に依存しています。 また、サービスプロバイダーは、特定のベンダーの製品の開発計画を実施できる強力な戦略的関係を確立できる必要があります。 このような関係が不可能な場合、サービスプロバイダーが成功することは非常に困難です。 OpenStackは、サービスプロバイダーに柔軟性を提供し、いつでもベンダーから解放され、ハードウェアとソフトウェアのどの組み合わせがベンダーと顧客に最適であるかを決定します。

サービスプロバイダーにとって興味深いプロジェクト

OpenStackには約12のプロジェクトが含まれていますが、カーネル以外のプロジェクトの一部は、他のプロジェクトよりもサービスプロバイダーの関心を引く可能性があります。 例：

熱

過去には、クラウドベースのエンタープライズサービスプロバイダーであるCarpathia Hostingで働いていました。 2009年頃、 OpenStack Heatプロジェクトが提供するものと同様のVMライフサイクル管理ソリューションと機能を提供する新興企業で働いていました。 実際、ある種の概念設計（設計図）または保存できるコードを通じてデータセンターを記述する方法が必要でした。 次に、このブループリントから新しいデータセンターブロックをプログラムでインスタンス化する運用機能が必要でした。 つまり、このスタートアップは、データセンタークラスを構築できるツールを提供し、その後、新しいオブジェクトをインスタンス化できました。 とてもクール！ 熱も同じように機能します。 これは、 AWS Cloudformation互換テンプレートを使用してOpenStack環境を調整する方法です。 OpenStackをデプロイするたびにHeatパターンを使用して、高度な自動化を実現することを強くお勧めします。 ここで 、Heatの良いガイドを見つけることができます。

セロメーター

すべてのサービスプロバイダーには、消費されたリソースの量と消費期間を決定する機能が必要です。 上記のように、機器に依存しない環境、および互換性のないタイプのネットワークとデータウェアハウジングを使用する場合、監視と管理を簡素化するために使用されるリソースを追跡する単一の統一された方法が必要です。 Ceilometerは、課金システムに統合できる測定データを提供するためにサービスプロバイダーが使用するOpenStackプロジェクトです。 詳細については、 ドキュメントを参照してください 。

皮肉

多くのサービスプロバイダーは、さまざまな（多くの場合、複雑で頭痛のする）方法を使用して「クリーン」サーバーのアセンブリを自動化しますが、OpenStackにはIronicプロジェクトがあり、単一のAPIを使用してこの機会を与えます。 Rackspaceなどの一部の企業は、OnMetalと呼ばれるIronicの独自バージョンを導入する意向を発表しています。 このプロジェクトの価値は、単一のAPIだけではありません。 サービスプロバイダーは、測定、オーケストレーション、ブロックデータストレージなど、「クリーンな」サーバー上のOpenStackのすべての機能を利用できます。



IronicはNova Bare Metalプロジェクトから登場し、その後廃止されました。 同時に、Ironicはまだインキュベーション段階にあり、チームはIcehouseのリリースでは公式に「ベータ安定」と見なし、ユーザードキュメントの作成に取り組んでおり、 バグを積極的に修正しています。 目標は、IronicをOpenStack Junoリリースで利用可能にすることですが、この目標は拡大できます。 成熟度に関しては、これは監視され、研究室内で検討される必要があるプロジェクトですが、産業レベルのプロジェクトではありません。 一般的に、私はこのプロジェクトと、それがサービスプロバイダーにどのように影響するかについて個人的に熱心です。

OpenStackには何が欠けていますか？

OpenStackは急速に開発されており、今後も継続していきます。 OpenStackコミュニティとこのセグメントのプレーヤーであるベンダーの両方は、顧客がすべての主要機能を使いやすくするために取り組んでいますが、まだギャップがあります。

参照アーキテクチャ

最も重要な問題の1つは、ユースケースに一致する参照アーキテクチャを見つけることです。 サミットを訪れると、素晴らしい会議の参加者になりますが、一番下の行は「どのアーキテクチャを選ぶべきですか？」という質問です。



ベンダーは多くのコードを提供し、OpenStackをソリューションと連携させようとしていますが、残念ながら、サービスプロバイダーが使用できるゴールドスタンダードは欠落しているようです。 現時点では、最も一般的なアーキテクチャはデータストレージにCephを、ハイパーバイザー/コンピューティングノードとしてKVMを使用しているようですが、標準のネットワークオプションは存在しません。

高可用性（HA）

今日のOpenStack内のほとんどのサービスはHAで保護できます。 「マジョリティ」という言葉を使用したことに注意してください。 現在、多くのサービスプロバイダーは、HAを提供するために基本的なインフラストラクチャを必要とする古いアプリケーションや遅延アプリケーションを使用している顧客を抱えています。 OpenStackプラットフォームは現在、インフラストラクチャ全体にHAを提供する既製の方法を提供していません。 これはその設計の目的ではありませんでした。 より簡潔にするため、OpenStackは現在、Nova計算ノードを実行するためのHAを提供していません。計算ノード自体に障害が発生した場合、VMは他のノードに自動的に切り替わりません。 OpenStackはNetflixと同じアプローチを使用しており、開発者がHAをアプリケーションに統合することに依存しています。 クラウド上で実際に実行されるアプリケーションは、インフラストラクチャの障害に耐えることができなければなりません。



技術の美しさは、すべての問題を解決できることです。 クライアントがHAを必要とする場合は、DRSなどのクールな機能をサポートするVMWareなど、デフォルトでHAを提供する別のハイパーバイザーを使用できます。 KVMの使用を継続したいクライアントは、たとえばNagiosやZabbixを使用して、これらのデバイスの動作を監視したり、サービスを自動的に再起動したりすることができます。



この問題は、私の同僚であるDmitry NovakovskyのブログでOpenStackの欠落機能について詳細に議論されました。

課金

誰が請求が必要ですか？ 冗談です。 前述のように、今日、OpenStackは使用されるリソースを監視するCeilometerプロジェクトを提供します。 困難な点の1つは、多くのサービスプロバイダーが独自の課金システムを使用しており、多くの場合これらが完全に個別のソリューションであることです。 おそらく、大規模なコミュニティはリスクを冒さず、何らかの公式な課金システムを作成しないため、顧客が既存の会計システムと統合したいベンダーと協力することが最善です。

サービスプロバイダー、それを現実にします！

サービスプロバイダーは、大きな競争のために最も困難な分野の1つで働いています。 ビジネスがより動的で効率的になることを可能にする大きな技術的変化が時々発生します。 OpenStackは、将来的に乗るのに最適な波のようです。



要約すると、サービスプロバイダーが注力する必要があるいくつかの重要な原則を強調できます。

1.ベンダーへのバインドを避けます。



2.自動化とオーケストレーションを積極的に適用します。



3.プラットフォームを自分でデプロイしようとしないでください。これは大きな頭痛の種です。その結果、FrankenStackが手に入ります。



4.ニーズに合ったソリューションの作成を支援するハードウェアとソフトウェアに公平なベンダーと協力します。



5.それに進み、OpenStackをデプロイします！



英語のオリジナル記事。