Hystax Cloud の移行: 雲に乗って

災害復旧ソリューション市場における若いプレーヤーの 2016 つが、XNUMX 年に設立されたロシアの新興企業、Hystax です。 災害復旧のテーマは非常に人気があり、市場の競争が非常に激しいため、このスタートアップは、異なるクラウド インフラストラクチャ間の移行に焦点を当てることにしました。 クラウドへの簡単かつ迅速な移行を組織できる製品は、オンランタのクライアント、つまりユーザーにとっても非常に役立つでしょう。 オンクラウド.ru。 こうして私は Hystax を知り、その機能をテストし始めました。 それがどうなったのか、この記事でお話しします。

Hystax の主な特徴は、さまざまな仮想化プラットフォーム、ゲスト OS、クラウド サービスをサポートする幅広い機能であり、どこからでもワークロードを転送できるようになります。

これにより、DR ソリューションを作成してサービスの耐障害性を高めるだけでなく、異なるサイトやハイパースケーラー間でリソースを迅速かつ柔軟に移行してコスト削減を高め、特定の時点で特定のサービスに最適なソリューションを選択することもできます。 タイトル写真にリストされているプラ​​ットフォームに加えて、同社は、Yandex.Cloud、CROC Cloud Services、Mail.ru などのロシアのクラウド プロバイダーとも積極的に協力しています。 2020年に同社がスコルコボに研究開発センターを開設したことも注目に値する。 

市場の多数のプレーヤーが XNUMX つのソリューションを選択したということは、適切な価格設定ポリシーと製品の適用性の高さを示しており、私たちはそれを実際にテストすることにしました。

したがって、私たちのテスト タスクは、私の VMware テスト サイトと物理マシンから、やはり VMware によって管理されているプロバイダーのサイトへの移行で構成されます。 はい、そのような移行を実行できるソリューションは数多くありますが、私たちは Hystax を普遍的なツールと考えており、考えられるすべての組み合わせで移行をテストすることは非現実的な作業です。 また、Oncloud.ru クラウドは特に VMware 上に構築されているため、ターゲットとしてのこのプラットフォームに大きな関心を持っています。 次に、基本的な動作原理について説明します。基本的な動作原理は一般にプラットフォームから独立しており、どの側の VMware も別のベンダーのプラットフォームに置き換えることができます。 

最初のステップは、システムのコントロール パネルである Hystax Acura を導入することです。

テンプレートから展開していきます。 何らかの理由で、私たちの場合は完全に正しくはなく、推奨される 8CPU の代わりに、半分のリソースを使用して 16Gb がデプロイされました。 したがって、忘れずに変更する必要があります。そうしないと、すべてが構築されている VM 内のコンテナー インフラストラクチャが起動せず、ポータルにアクセスできなくなります。 で 導入要件 必要なリソースとすべてのシステム コンポーネントのポートが詳細に説明されています。 

テンプレートから IP アドレスを設定するのも困難だったので、コンソールから変更しました。 この後、管理 Web インターフェイスに移動して、初​​期構成ウィザードを完了できます。 

エンドポイント – vCenter の IP または FQDN。 
ログインとパスワード – これは明確です。 
ターゲット ESXi ホスト名は、レプリケーションが実行されるクラスター内のホストの XNUMX つです。 
ターゲット データストアは、レプリケーションが実行されるクラスター内のデータストアの XNUMX つです。
Hystax Acura コントロール パネルのパブリック IP – コントロール パネルが利用できるアドレス。

ホストとデータストアに関して少し説明が必要です。 実際、Hystax レプリケーションはホスト レベルとデータストア レベルで機能します。 次に、テナントのホストとデータストアを変更する方法を説明しますが、問題は異なります。 Hystax はリソース プールの操作をサポートしていません。 レプリカは常にクラスターのルートに移動します (この資料の執筆時点で、Hystax の担当者が更新バージョンをリリースし、リソース プールのサポートに関する私の機能リクエストをすぐに実装しました)。 vCloud Director もサポートされていません。つまり、 私の場合のように、テナントがクラスター全体に対する管理者権限を持たず、特定のリソース プールに対してのみ管理者権限を持ち、Hystax へのアクセス権を与えた場合、テナントはこれらの VM を個別に複製して起動できますが、 VMware インフラストラクチャではそれらを参照できません。VMware インフラストラクチャにはアクセスできるため、仮想マシンをさらに管理できます。 クラスター管理者は、VM を目的のリソース プールに移動するか、vCloud Director にインポートする必要があります。

なぜ私はこれらの点にこれほど注目するのでしょうか? なぜなら、私が製品のコンセプトを理解する限り、顧客は Acura パネルを使用して移行や DR を独自に実装できるはずだからです。 しかしこれまでのところ、VMware のサポートは、同様のメカニズムがすでに実装されている OpenStack のサポートのレベルよりわずかに遅れています。 

しかし、展開に戻りましょう。 まず、パネルの初期セットアップ後、システムに最初のテナントを作成する必要があります。

ここのフィールドはすべて明確です。クラウド フィールドについてのみ説明します。 初期構成時に作成した「デフォルト」クラウドがすでにあります。 ただし、各テナントを独自のデータストアと独自のリソース プールに配置できるようにしたい場合は、顧客ごとに個別のクラウドを作成することでこれを実装できます。

新しいクラウドを追加するフォームでは、初期構成時と同じパラメータを指定し (同じホストを使用することもできます)、特定の顧客に必要なデータストアを指定します。また、追加パラメータで必要なリソースを個別に指定できるようになりました。プール {"resource_pool" : "YOUR_POOL_NAME"} 

お気づきかと思いますが、テナント作成フォームにはリソース割り当てやクォータに関する情報は何もありません。システムにはこれらの情報は何もありません。 同時レプリカの数、レプリケーション用のマシンの数、またはその他のパラメータによってテナントを制限することはできません。 これで、最初のテナントが作成されました。 ここで、完全に論理的ではありませんが、クラウド エージェントのインストールという必須の作業があります。 エージェントは特定の顧客のページにダウンロードされるため、これは非論理的です。

同時に、作成されたテナントに関連付けられることはなく、すべての顧客がこのテナントを介して (または、展開している場合は複数の) 作業を行うことになります。 10 つのエージェントは XNUMX の同時セッションをサポートします。 XNUMX 台のマシンを XNUMX セッションとしてカウントします。 ディスクの数は関係ありません。 現在のところ、VMware の下で Acura 自体にエージェントをスケーリングするメカニズムはありません。 もう XNUMX つ不快な瞬間があります。アキュラのパネルからこのエージェントの「処分」を確認して、さらに配備する必要があるかどうか、または現在の設置で十分かどうかを結論付ける機会がありません。 結果、スタンドはこんな感じになりました。

カスタマー ポータルにアクセスするための次のステップは、アカウント (そして最初に、このユーザーに適用されるロール) を作成することです。

これで、お客様はポータルを独立して使用できるようになりました。 彼が行う必要があるのは、ポータルからエージェントをダウンロードして自分側にインストールすることだけです。 エージェントには、Linux、Windows、VMware の XNUMX 種類があります。

最初の XNUMX つは、物理マシンまたは VMware 以外のハイパーバイザー上の仮想マシンにインストールされます。 追加の設定は必要なく、エージェントがダウンロードされ、ノックする場所がすでに認識されており、文字通り XNUMX 分で車が Acura パネルに表示されます。 VMware エージェントの場合、状況はもう少し複雑です。 問題は、VMware のエージェントも、すでに準備され、必要な構成が含まれているポータルからダウンロードされることです。 ただし、VMware エージェントは、Acura ポータルについての知識に加えて、それが展開される仮想化システムについても知っておく必要があります。

実際には、最初に VMware エージェントをダウンロードするときに、システムはこのデータの提供を求めます。 問題は、セキュリティに対する普遍的な関心が高まっている現代において、誰もが他人のポータルに自分の管理者パスワードを表示したいわけではないということですが、それは十分に理解できます。 導入後、内部からエージェントを構成することはできません (ネットワーク設定のみを変更できます)。 特に慎重な顧客にとっては困難が予想されます。 

したがって、エージェントをインストールした後、Acura パネルに戻ってすべての車を確認できます。

ここ数日間システムを使用して作業しているため、さまざまな状態の車があります。 私はすべてをデフォルト グループに入れていますが、必要に応じて別のグループを作成し、そこに車を転送することも可能です。 これは何も影響しません。作業をより便利にするためのデータとそのグループ化の論理的な表現のみです。 この後に最初に行う必要がある最も重要なことは、移行プロセスを開始することです。 これは手動で行うことも、すべてのマシンを一度に一括して行うなど、スケジュールを設定することによって行うこともできます。

Hystax は移行向けの製品として位置づけられていたことを思い出してください。 したがって、複製されたマシンを実行するために DR 計画を作成する必要があるのは驚くべきことではありません。 計画は、すでに同期状態にあるマシンに対して作成できます。 XNUMX つの特定の VM とすべてのマシンの両方を一度に生成できます。

DR 計画を生成するときのパラメータのセットは、移行先のインフラストラクチャによって異なります。 VMware 環境では、最小限のパラメータのセットが利用可能です。 マシンの再 IP もサポートされていません。 この点に関して、次の点に注目します。VM の説明の「サブネット」パラメーター: 「VMNetwork」。ここで、VM をクラスター内の特定のネットワークにバインドします。 ランク – 複数の VM を移行する場合に関連し、起動される順序を決定します。 フレーバー – VM 構成を説明します。この場合は、1CPU、2GB RAM。 サブネット セクションでは、「サブネット」: 「VMNetwork」が VMware の「VM ネットワーク」に関連付けられることを定義します。 

DR 計画を作成する場合、ディスクを異なるデータストアに「分散」する方法はありません。 これらは、このクライアント クラウド用に定義されたのと同じデータストア上に配置されます。異なるクラスのディスクがある場合、マシンの起動時に問題が発生する可能性があります。また、VM を起動して Hystax から「分離」した後も、必要なデータストアへの別の移行ディスクが必要です。 そうすれば、私たちがしなければならないのは、DR 計画を開始し、車両が回復するのを待つことだけです。 P2V/V2V 変換プロセスにも時間がかかります。 私の最大のテスト マシン (100 つのディスクを備えた 10 GB) では、最大 XNUMX 分かかりました。

この後、実行中の VM、その上のサービス、データの整合性を確認し、その他のチェックを実行する必要があります。 

その場合、次の XNUMX つの方法があります。 

1. 削除 – 実行中の DR プランを削除します。 このアクションでは、実行中の VM がシャットダウンされるだけです。 これらのレプリカはどこにも行きません。 
2. デタッチ – レプリカ車をアキュラから引き離します。つまり、 実際に移行プロセスを完了します。 

このソリューションの長所: 

• クライアントとプロバイダーの両方からのインストールと構成が簡単。 
• 移行のセットアップ、DR 計画の作成、レプリカの起動が簡単。
• サポートと開発者は、見つかった問題に非常に迅速に対応し、プラットフォームまたはエージェントのアップデートを使用して問題を修正します。 

コンズ 

• VMware のサポートが不十分です。
• プラットフォームからのテナントに対する割り当てが存在しない。 

また、機能リクエストをまとめてベンダーに送信しました。

1. Cloud エージェント向けの Acura 管理コンソールからの使用状況の監視と展開。
2. テナントの割り当ての可用性。 
3. 各テナントの同時レプリケーションの数と速度を制限する機能。 
4. VMware vCloud Director のサポート。 
5. リソース プールのサポート (テスト中に実装)。
6. Acura パネルのクライアント インフラストラクチャから認証情報を入力せずに、エージェント自体から VMware エージェントを構成できる機能。
7.  DR計画実行時のVM起動プロセスの「見える化」。 

私に大きな批判を引き起こした唯一のことは、ドキュメントでした。 私は「ブラックボックス」があまり好きではなく、製品が内部でどのように動作するかについての詳細なドキュメントがあることを好みます。 そして、AWS と OpenStack については多少なりとも製品について説明されていますが、VMware についてはドキュメントがほとんどありません。 

インストール ガイドには Acura パネルの展開についてのみ説明されており、クラウド エージェントも必要であるという事実については一言もありません。 製品仕様も充実していて良いですね。 AWS と OpenStack を例として使用してセットアップを「最初から最後まで」説明したドキュメントがあり (ブログ投稿のように見えますが)、非常に小規模なナレッジベースもあります。 

一般に、これは私が慣れ親しんでいる大手ベンダーのドキュメント形式とはまったく異なるため、完全には快適ではありませんでした。 同時に、システムが「内部」でどのように動作するかの微妙な点については、このドキュメントでは答えが見つかりませんでした。多くの質問はテクニカル サポートに問い合わせて解決する必要があり、そのためスタンドの展開と実行のプロセスが大幅に遅れました。テスト中。 

要約すると、私は全体的にこの製品とその仕事に対する会社のアプローチが気に入ったと言えます。 はい、欠点はあります。(VMware に関連して) 機能が非常に重大に欠如しています。 まず第一に、同社が依然としてパブリッククラウド、特に AWS に注力していることは明らかであり、一部の人にとってはこれで十分でしょう。 多くの企業がマルチクラウド戦略を選択している今日、このようなシンプルで便利な製品があることは非常に重要です。 競合他社と比較して価格が大幅に安いことを考慮すると、この製品は非常に魅力的です。

チームメンバーを募集しています 主任監視システムエンジニア。 もしかしてそれはあなたですか？

出所： habr.com