私はOpenStackに1～8年間携わってきました。ABCからHI、KOまで

ABC、HI、KO における OpenStack の経験

2010 年末、通信グレードのサポート プラットフォームとビジネスの仮想化の必要性から、私は ZTE で組み込み Linux からクラウド コンピューティングへの移行を開始しました。

当時、OpenStack のバージョンはまだ A、B、C の段階でした。威厳がありスタイリッシュな CloudStack、簡潔で明快な OpenNebula、高級感があり雰囲気のある Eucalyptus と比較すると、これらは IaaS 初期の 4 人の小さなドラゴンと総称できます。その中で、Eucalyptus は学術界で広く議論されており、China Mobile の大規模クラウドは OpenNebula を使用しており、CloudStack は Citrix に買収されましたが、OpenStack はまだ初期段階にあります。あっという間に8年が経ちました。現在、これら 3 つはこの分野から姿を消すか消滅し、少なくともオープンソースの世界では、ライバルのいない OpenStack が単独でトップの座に君臨しています。だからため息が出るのは必然です。

当時はこれら 4 つのオープンソース IaaS プロジェクトの見通しが不明確で、どれが優れているかを見分けるのが難しかったため、私たちは全員でコンパイル、デプロイ、ソースコードレベルの予備調査を実施しようとしました。私たちが最も注目したコードは OpenNebula でした。第一に、そのシンプルでわかりやすい軽量アーキテクチャ、第二に C++ で実装されているため、組み込み C 開発の経験があるチームでも簡単に始められるという点です。結局のところ、当時は Python はまだ普及していませんでした。最終的に、各社の強みを融合し、通信グレードの仮想化管理プラットフォーム「TECS」をゼロから開発しました。最初は最下層で Xen を使用し、その後 KVM をサポートしました。発売後は、ZTEのGoTaシステム、コアネットワークなどの通信ビジネスシーンで使用されました。

TECS プラットフォームの一般的なサポート レイヤーには、OpenNebula ソリューションを活用し、マルチスレッド、マルチプロセス、マルチノード、およびより豊富なレベルをサポートする通信モードに変換される、Qpid に基づく AMQP メッセージ キューが含まれています。このメカニズムは、異常なトランザクションの複数の並列ステップの一括操作ロールバックをサポートする有向非巡回グラフの操作トランザクション システムを実装するために使用されます。もちろんサポートレイヤーとしては、通信以外にも、シェル、タイマー、シリアル化、データベース、例外処理などの共通コンポーネントもあります。このサポートレイヤーの設計書だけでも100ページ以上あったと記憶しています。

2013 年までに、OpenStack は Havana および IceHouse バージョンをリリースしました。これは、ABC からこんにちはと言う時期が来たことを示しているように思われました。通信事業者は NFV を重視しているため、サポートを提供し、より広範なテクノロジー エコシステムを進化させるオープンな仮想化プラットフォームが必要です。そのため、当時のチームは、3 年間かけて構築してきた仮想化プラットフォームを仕方なく放棄し、OpenStack の I バージョンの保守に切り替えざるを得ませんでした。最初は、OpenStack の機能はすべて以前に使用したことがあるものであり、詳細な安定性の要件は通信グレードのプラットフォームの要件とは比較にならないため、常に少し心理的に嫌悪感を感じていました。しかし、新しいビジネス機能の二次開発では、OpenStack の統一されたサービス ゲートウェイ エントリ、実装層の柔軟性の高い動的プラグイン メカニズム、シングル スレッドのマルチコルーチン サービス フレームワーク、マイクロサービス形式による拡張アイデア、Python 言語の迅速な実装などが驚異的です。まるでレゴブロックで遊ぶように、高度で大胆なコンセプトで、無数の既存のオープンソースプロジェクトを柔軟に組み立てて、商用グレードの要件を満たす巨大なプラットフォームを構築しているように感じます。 2年間の研究開発とメンテナンス投資を経て、豊富な建築設計の経験を積んできました。

その後、OpenStack との関係は、今日のクラウド デスクトップ分野にまで広がりました。 OpenStack は、初期の Kilo からバージョン 2.0 の Ocata まで、他のオープンソース IaaS プロジェクトを完全に打ち負かし、その地位を維持し、自らの状況を安定させる段階に達しました。 OpenStack コードの 5 つのコア コンポーネント (keystone、nova、glance、cinder、neutron) がしっかりと確立されています。バージョンの違いにより、実装層で細部の微調整が主に行われるため、可用性は問題になりません。クラウド プラットフォームの実際のユーザーの多くは、こうしたコード レベルの変更にはほとんど注意を払っておらず、独自のアプリケーション シナリオに重点を置いています。

孤立したままでいることに満足している Linux カーネル サークルと比較すると、OpenStack は、上位レベルの管理プラットフォーム レベルのオープン ソース プロジェクトとして、新規参入者がすぐに開始できるようにする手順コードを備えています。これは、クラウド コンピューティング テクノロジの急速な発展とも一致しており、開発者が集団で容易に想像し、爆発的に成長することを可能にします。そのため、コアコンポーネントが定着するや否や、saharaやheatをはじめとするさまざまな大規模プロジェクトが次々と登場し、アーキテクチャ全体の技術的影響力が少し拡大しすぎてしまいました。実際、このような統一された基本プラットフォームは、WeChat アプレットやモバイル アプリなどのインターネット アプリケーションとは異なります。豊富な実際の運用および保守経験と、基礎となる実装メカニズムの習得が必要です。急いで立ち上げたプロジェクトの運用環境の安定性と可用性は疑問です。もちろん、このような状況では、オープンソースの性質の利点を否定することはできません。普遍的な大規模プラットフォームであるため、包括的かつ寛容でなければならないことを意味します。数え切れないほどのコンポーネント、プラグイン、技術的なポイントが現れたり消えたり、時代に適応したり、あるいは自ら消滅したりしますが、コアとなるフレームワークは常に存在し、パルテノン神殿のように永遠に立っています。それ自体が注目に値することです。ポパーが『開かれた社会とその敵』で述べたように、良い社会とは開かれた社会であり、開かれた社会とはあらゆる種類の矛盾した考えが存在する社会である。この矛盾こそが社会に多様な選択肢と可能性を与え、社会をより良くしていくのです。逆に、閉鎖的な社会は、統一的で単純ですが、矛盾や選択の対峙を失うため、ずっと間違った方向に進み、退行してしまいます。

デスクトップで OpenStack について語る

クラウド デスクトップと OpenStack についてお話しましょう。 OpenStack 自体は管理プラットフォームです。ユーザーに実際の価値をもたらすのは、シナリオベースの活用です。結局のところ、ステージをセッティングすることは、ショーを演じるほど目を引くものではありません。クラウド デスクトップは、クラウド プラットフォーム上の街路や路地のいたるところで行われる素晴らしいショーです。コンピュータのデスクトップは、一日中見ていても飽きないアプリケーションです。政治の場であろうと遠く離れた場所であろうと、あらゆる分野で欠かせないものであり、その応用シナリオは多岐にわたります。人々にとって非常に身近なアプリケーションの場合、移植性、使いやすさ、セキュリティ、ユーザー エクスペリエンスはすべて避けられないトピックです。 IaaS の人気が高まるにつれ、デスクトップ上のクラウド コンピューティングが紛れもない選択肢となりました。

しかし、デスクトップ仮想化はクラウド コンピューティングより前に登場したため、IaaS について議論する際にデスクトップ クラウドが言及されることはほとんどないようです。 OpenStack 以前にも、すでにさまざまなデスクトップ仮想化管理システムが存在していましたが、複数のコンピューターの管理システムを自分で開発するのはそれほど複雑な作業ではないため、現在までその数は増加の一途をたどっています。そのため、クラウドデスクトップも名前に「クラウド」という言葉が入っていますが、IaaSと比較されることが多く、それぞれにメリットがあります。実際、私が開発した小型の仮想マシン管理システムは、数本のネジで締められる程度の小規模な場面で使用できます。ただし、大規模に展開されると、デスクトップ エクスペリエンスを除いて、管理プラットフォーム全体の高可用性、柔軟性、ホット マイグレーション、ストレージ バックアップ、および二次開発が限界に達します。まるで個人の畑で育てたおかずのようです。味はよりオーガニックですが、大口顧客への定期供給には供給不足です。

クラウド デスクトップ管理プラットフォームでは、OpenStack の最も成熟した 5 つのコンポーネント (keystone、nova、glance、cinder、neutron) のみを使用できるため、ユーザーにとって大きなメリットとなります。さらに、現在のデスクトップ オペレーティング システムはコンテナー内で実行できず、K8S などのコンテナー プラットフォームには興味がありません。 OpenStack プラットフォームの開発に多大な労力を費やす必要はなくなりました。デスクトップ仮想化アプリケーション シナリオにおける安定性と成熟度により、メンテナンス担当者は一日中心配する必要がなくなりました。

さらに一歩進むと、VDI デスクトップのコアコンテンツは仮想化であり、プラットフォーム管理レイヤーに依存する必要はありません。たとえば、当社の現在のクラウド デスクトップ プラットフォーム バージョン 3.0 は、既存の IaaS プラットフォームやハイパーコンバージド環境に仮想マシン イメージやコンテナ イメージの形式でインストールでき、真の DaaS になります。これにより、プライベート クラウド メーカーは開発を繰り返す必要がなくなり、プライベート クラウド ユーザーは構築を繰り返す必要がなくなります。当社では、デスクトップ アプリケーションにさらに多くの管理機能の入り口を提供できるオープンで標準化されたインターフェイス システムを備えているため、デスクトップ システムの実行には OpenStack クラウド プラットフォームの使用を強く推奨しています。クラウド プラットフォームの観点から見ると、当社のクラウド デスクトップは、OpenStack オープン ソース プロジェクトを最も適切なシナリオベースで使用します。

8 年間の開発を経て、OpenStack は多くの支持者を持つホットな話題から、市場の隠れた宝石へと変化しました。基本機能が成熟し安定し、バージョン差が小さくなると、必然的に見えなくなるでしょう。すべてが過去になったとき、深い非難と深い愛情の声が数多く聞かれるでしょう。プラットフォームとしての役割をしっかり果たし、さまざまなプロジェクトや製品領域で主力としての役割を果たしてもらったほうが良いでしょう。これは、長年にわたって蓄積されてきたオープンソース テクノロジの価値を証明する最良のものとなるでしょう。

著者について:

南京 Jimin Technology のチーフアーキテクトである Zhang Wenjian 氏は、OpenStack VDI に注力し、China Open Source Cloud Alliance のデスクトップクラウド標準の策定に参加し、Jimin クラウドプラットフォームバージョン 1.0 および 2.0 の研究開発を統括しています。