HyperBDR は、クラウド ネイティブ コンセプトに基づいた移行および災害復旧製品です。コアビジネスシナリオは、ブロックレベルの差分方式でソースエンドをクラウドネイティブストレージに同期することです。現在、ブロックストレージとオブジェクトストレージのサポートを実現しています。最後に、特許取得済みの Boot-in-Cloud テクノロジーを使用して、ワンクリックでビジネス システムを使用可能な状態に復元し、クラウド ネイティブのオーケストレーション機能を最大限に活用して、移行や災害復旧などのビジネス シナリオのさまざまなニーズに対応します。 HyperBDRは現在、ソースオペレーティングシステムの約10のメジャーバージョンをサポートしています( このような大規模な状況では、テスト範囲を達成するために人力だけに頼るのは明らかに非現実的です。コアビジネスシナリオをテストするには、自動テスト方法を導入する必要があります。これにより、自動テストのニーズを満たすだけでなく、開発者は日々の開発中に新しく開発された機能がコアプロセスに与える影響を迅速に把握できるようになり、製品の安定性と信頼性がさらに向上します。 問題点分析まず、手動テストによる HyperBDR 製品テストの問題点を見てみましょう。 問題点1: テストケースが多すぎることと人材が不足していること前述のソース側とターゲット側の規模では、基本的なスモーク テストをいくつか実行したとしても、完全なテストには 100 を超えるシナリオが残ります。例えば:
このように計算すると、テストには 171 のシナリオがあります。ユースケースはそれほど多くなく、一度実行するのにそれほど時間はかからないと言う学生もいるかもしれません。そこで、テスト プロセスにおける HyperBDR の 2 番目の問題点であるテスト サイクルの問題について見てみましょう。 問題点2: テストサイクルが長いビジネス テストとは異なり、HyperBDR の単一シナリオのテストには非常に時間がかかります。初期のリソース準備時間とさまざまな構成時間を無視して、データの同期と起動プロセスのみを分析してみましょう。
したがって、単一のホストでテストを処理する必要があり、これには少なくとも 2 時間かかります。上記で想定したシナリオによれば、1 日のテストの後でも、1 つのクラウドの完全なテストを完了できない可能性があります。おそらく、ここにいる学生の中には、なぜ並行処理を行わないのかと尋ねる人もいるでしょう。ここで、3 番目の問題点であるコストについて考えます。 問題点3: テストコスト同時実行性を完全に採用できない理由は、ネットワーク帯域幅の制限によるものです。当社の社内研究開発環境では、外部ネットワーク帯域幅はわずか 40Mbps です。上記のテストシナリオでは、帯域幅をフルに活用することを前提として、500G データの完全なデータ伝送時間は約 35 時間です。これにより、テスト サイクルがさらに延長されることは間違いありません。 もう 1 つのポイントは、ソース側に非常に多くの環境があり、さまざまなシナリオが追加された場合、ソース側で必要なコンピューティング リソースとストレージ リソースが膨大になるということです。製品が繰り返し改良されるにつれて、占有されるリソースはますます増えていきます。そこで、この問題を解決するために、ローカルリソースの不足の問題を解決するためにパブリッククラウド環境を導入することにしました。リソース使用の特性に基づいて、最適なコストを実現するために従量課金制をメインに採用しています。実際のテストプロセス中に生成される主なクラウド リソースには、コンピューティング、ブロック ストレージ、オブジェクト ストレージ、ネットワークなどがあります。自動テストでは、リソース サイクルを可能な限り短縮し、無駄を回避し、リソースをタイムリーにクリーンアップします。さらに、リソースの残留を回避するために、リソースの課金を監視する必要があります。 需要分析基本原則: 車輪の再発明はしない新たな開発者を追加することなく、自動テストの開発作業が実行されました。開発作業は主に R&D チームによって行われ、テスト チームはユーザーとして機能します。ただし、開発チームには独自の製品開発タスクがあるため、製品開発に影響を与えないようにするために、車輪の再発明ではなく、既存の技術蓄積とサードパーティのコンポーネントを可能な限り再利用して、自動テストの目標を柔軟に達成するという最初の原則が策定されました。 要件1: ソースエンドの自動作成と破棄最初に解決すべきことは、ソース リソースの柔軟な作成です。これを行う最も簡単な方法は、Terraform を使用してさまざまなテンプレートを組み合わせて、ソース リソースを作成および破棄する機能を実装することです。このようにして、ソースエンドとして、少なくとも Alibaba Cloud、Huawei Cloud、AWS、OpenStack、VMware の 5 つの主要クラウドの機能が揃います。 解決すべき2番目の課題は、エージェントを使用した自動登録の問題です。後続のプロセスで HyperBDR によって認識されるには、ソース サーバーにエージェントをインストールして登録する必要があります。オペレーティングシステムによって、Linux と Windows システムに分かれます。 Linux では、SSH を使用してシステムにログインし、インストールを実行できます。一方、Windows では、WinRM を使用してエージェントをインストールできます。 3 番目に、スケーラビリティにより、シナリオベースのニーズをより多く満たすことができます。 Terraform 自体はリモート実行モードを提供していますが、その後のスケーラビリティのために、Ansible と組み合わせて関連機能を実装することができます。将来のテスト シナリオには、ソース側でのさまざまなアプリケーション データの整合性のテストも含まれる可能性があります。この場合、ソース側の準備時に追加のアプリケーションとデータの準備が必要になります。 Terraform と Ansible を組み合わせて使用すると、最大限の柔軟性を実現できます。 要件2: スケーラビリティ要件を満たすためにテストシナリオをテストツールから分離する簡単に言えば、テストの自動化の度合いが高くなるほど、開発コストが高くなり、その後のメンテナンスのコストも高くなります。したがって、自動テストを計画する際には、テスト シナリオとテスト ツール間の結合を減らす必要があります。これは、テスト シナリオのスケーラビリティを最大化する唯一の方法です。つまり、テスト シナリオはテスト ツールの柔軟な組み合わせによって実装され、両者のギャップはさまざまな構成ファイルを通じて統合されます。 具体的には、HyperBDR の自動テスト計画では、シナリオを次のように定義します。
テスト ツールによって提供される機能を次のように定義します。
上記のすべての手順は個別に実行でき、各手順が完了したら統合された CSV ファイルに書き込むことで、接続時にこのファイルを通じて手順を統合できるようになります。その後、CSV ファイルをデータ視覚化ツールに直接プッシュして、トレンド表示効果を作成できます。 要件3: シナリオの自動化とテスト失敗のタイムリーな通知を実現する実際のアプリケーションでは、このツールは研究開発から納品までのほぼすべてのプロセスで必要になります。たとえば、R&D の同僚は、コードを提出する前に基本プロセスを少なくとも 1 回テストする必要があります。デリバリー担当者もスクリプトを使用して、デモ環境を構築する際の効率を向上させることができます。テスト担当者の間ではこのツールに対する強い要望があります。 さまざまなシナリオでの実際の自動化作業は、Jenkins タスクによって連続して完了し、テストが失敗した後、全員に時間内に通知され、できるだけ早く変更を加えることができます。たとえば、メイン プロセスの安定性を確認するために、1 時間ごとに小規模なスモーク テストを実行します。クラウド プラットフォームの安定性を確認するために、毎朝基本的なスモーク テストを実行します。メインのオペレーティング システム バージョンの安定性を確認するために、週に 1 回大規模なスモーク テストを実行します。これにより、人的リソースを節約できるだけでなく、バージョン内の不安定な要因をできるだけ早く発見できるようになります。 実装全体的なアーキテクチャ上記の要件に従って、完全なツールは次の 2 つの部分で構成されます。
Terraformはリソースを作成し、リモートでコマンドを実行しますTerraform の使い方については多くのチュートリアルがあるので、ここでは詳しく説明しません。ここでは主に、Terraform と AutoTest 間のスクリプト連結を実現するために Terraform が使用するいくつかの詳細な機能について説明します。 組み込みメソッド remote-execTerraform はリソースを作成すると、エージェントを自動的にインストールし、HyperBDR に登録します。リモート ホスト操作の複雑さを軽減するには、新しく作成されたホストにエージェントをアップロードし、自動登録のためにインストールします。 Terraform 自体は、プロビジョナーを通じてリモート接続、アップロード、実行を提供します。基本的な構造は次のとおりです。 リソース"null_resource" "ins_centos7_run_remote_command" { Windowsの場合、接続方法はwinrmとなります。ここで注意すべき点は、開始されたリソースで WinRM が有効になっている必要があることです。有効になっていないと、このメソッドは接続に使用できません。 WinRM を有効にする 1 つの方法は、ユーザー データ メソッドを使用することです。具体的な例を挙げます リソース"null_resource" "run_windows_remote_command" { Ansibleとの統合Terraform のリモート実行方法を直接使用するのは簡単ですが、より複雑なシナリオをサポートするには柔軟性が足りないため、リソースの制御を強化するために Ansible を導入します。 remote-exec に対応するコマンドは local-exec で、ローカルの Ansible コマンドを実行してリモート リソースを制御します。ディレクトリ構造は次のとおりです。 。 Ansible Playbook は、Terraform で次のように実装された別のディレクトリに保存されます。 リソース"null_resource" "run_ansible" { 出力Terraform と AutoTest を接続するには、実行ごとに基本的な情報を含むホスト リストを Terraform が出力する必要があります。もちろん、これは Ansible Inventory ファイルとしても使用できます。 local_file リソースを使用して、ファイルに書き込みたいコンテンツを直接出力します。具体的な実装は以下のとおりです。 リソース"local_file" "inventory" { Terraform ローカル キャッシュよく知られている理由により、Terraform は init コマンドを実行するときに GitHub にアクセスするため、インストール プロセス中に失敗する可能性が一定程度発生します。障害のリスクを軽減するためには、ネットワークへのアクセスによって生じるリスクを回避するためにローカル キャッシュを使用する必要があります。まずディレクトリ構造を見てみましょう。 。 install.sh は、ダウンロードした terraform バイナリ パッケージを解凍してインストールし、plugins-cache を $HOME/.terraform.d ディレクトリにコピーし、最後に .terraformrc ファイルを生成するために使用されます。 plugin_cache_dir = "$HOME/.terraform.d/plugins-cache" 実際の実行では、ほとんどのオンライン ドキュメントには記載されていないパラメータを指定してローカルでインストールが実行されます。 terraform init -無視-リモート-バージョン plugins-cache を構築するときは、主に terraform provider mirror コマンドを使用します。次に例を示します。 terrform プロバイダーは、 / path / to / your / plugins - cache をミラーリングします この目的のために、キャッシュを自動的に更新するスクリプトをプロジェクトに追加しました。 # !/ bin / bash タスクフローは実行プロセスをシリアル化してスケーラビリティを実現しますAutoTest ツールの開発中は、開発を簡素化するために、主に OpenStack のいくつかの Python モジュールを再利用しました。使用された主なモジュールは stevedore と taskflow でした。また、CSV ファイルの操作を簡略化するために、操作には pandas ライブラリを使用しました。 ドライバーモードを使用してコマンドラインを拡張するsetup.cfg では、次のドライバーを定義します。各命令は、タスクフローの実行プロセスに対応します。 タスク= コードがロードされると、異なるパラメータを入力することで、対応するパイプラインが動的にロードされます。 def run_tasks ( args 、 hosts_conf 、 hyperbdr_conf ) : タスクフローを使用してプロセスを接続するTaskflow は OpenStack の非常に優れたライブラリです。タスク実行プロセスを抽象化し、上位層の順次ビジネス シナリオの使用を容易にします。そのため、アプリケーションにおける開発プロセスを簡素化するために、タスクフロー上で適切な抽象化を行い、実行プロセスと実行内容を分離します。つまり、実行は基本クラスで実行され、関連する特定のタスクのみをサブクラスで定義する必要があります。 基本クラスのコード例は次のとおりです。 タスクフロー.enginesをインポートする 具体的なサブクラスの実装は次のとおりです。 タスクフローからタスクをインポート 上記の抽象化により、HyperBDR SDK を使用してさまざまなアプリケーション シナリオを迅速に実装し、その後のスケーラビリティ要件を最大限に満たすことができます。 Jenkins シリアル自動テストプロセスツールを実装すると、手動でのステップバイステップ実行のニーズを満たすだけでなく、Jenkins を使用してプロセスを接続して、シナリオ自動化テストのニーズを満たすこともできます。 シーンオートメーション自動シナリオテスト用に、git に autotest-cases という名前の新しいプロジェクトを作成します。例の構造は次のとおりです。 。 ディレクトリにはシナリオに基づいて名前を付け、各ディレクトリには個別の Terraform テンプレートと hyperbdr 構成ファイルのセットが含まれます。このように Jenkins タスクを定義すると、テストシナリオをディレクトリとして扱い、柔軟に読み込むことができます。 Jenkinsifle の基本構造は次のとおりです。 パイプライン 各段階を定義することで、各段階の結果と失敗の理由を明確に理解できます。最後に、結果を DingTalk に送信して、現在のコードの安定性をタイムリーに把握できます。 例外処理自動テストプロセス全体において、いずれかのステップが失敗した場合は、次のテストに影響が及ばないように、リソースを時間内にクリーンアップする必要があります。したがって、リソースのクリーンアップを強制するためにグローバル障害が定義されます。 役職{ 要約する現在、HyperBDR の日常的な開発では、自動テストのシナリオを継続的に改善していますが、今回の実装を経て、自動テストに対する新たな理解が得られました。 自動テストは完全なカバレッジを達成できますか?少なくとも HyperBDR ではそうではありません。HyperBDR のソース側とターゲット側によってテスト シナリオが予測不可能になり、自動化されたスクリプトを通じて複雑なシナリオ、特に異常なシナリオを完全にシミュレートすることが困難だからです。たとえば、ソース ホストの破壊テストやデータ転送リンクに対する一部の攻撃シナリオでは、期待どおりに動作しているかどうかを確認するために監視が必要です。これらのシナリオでは、自動テスト シミュレーションを使用した開発コストが高すぎるうえ、考えられるシナリオが絶えず変化するため、迅速なバージョン反復のニーズを満たすことができません。もちろん、これに専任する数百人規模の研究開発チームがある場合は、話は別です。しかし、このような投入産出比率が合理的であるかどうかは議論する価値がある。 自動テストでは、どれを「自動化」し、どれを「手動」にすればよいのでしょうか?自動テストを実装するときは、盲目的に「自動化」を追求しないでください。自動化の度合いが高くなるほど、開発コストが高くなり、柔軟性が低下し、結果として利用可能なシナリオが少なくなり、予想に反することになります。 HyperBDR シナリオを例にとると、各プロセスを分割して部分的な自動化を実現し、複数のツールでツールセットを形成し、プロセスを直列に接続してシナリオを構築するのがよいでしょう。 今後の計画は何ですか?製品が繰り返し改良されるにつれて、自動テストは拡大し続けます。エージェント方式のサポートに加えて、エージェントレスおよびブロック ストレージ自動化のサポートも強化されます。ただし、これらの開発モデルはすべて上記のフレームワークに基づいています。上記のテストは主にインターフェーステスト用です。フロントエンドテストにも Selenium が導入されますが、実装の範囲は依然としてメインラインプロセスが中心となります。最後に、データ テスト シナリオを徐々に充実させ、データ整合性に関するテストを追加します。 DevOps の概念が従来の研究開発プロセスを徐々に変化させていく中で、自動テストは不可欠な要素となり、将来の開発者にとって必須のスキルの 1 つとなっています。ただし、自動テストは製品開発とは異なります。最も適応性の高い自動テスト ツールを作成するには、「解釈」という考え方を学び、テストのニーズとシナリオを理解する必要があります。 |
<<: [クラウド ネイティブ] 一般的な Helm コマンド (チャートのインストール、アップグレード、ロールバック、アンインストールなど)
>>: Google Cloudの成長が鈍化し、Alphabetの純利益が急落
百度が引き起こした内分泌障害の時代には、たとえ普通のウェブサイトであっても、独創性にこだわっていても...
DA International Group Ltd. の子会社である alphavps.bg は ...
データ複製は冗長なプロセスです。冗長性により可用性が向上し、読み取り負荷を効果的に分散できます。デー...
10月14日、海外メディアは、新型コロナウイルスの流行が多くの企業に影響を与えているが、一部の企業は...
マイクロソフト社の Azure Stack、アマゾン ウェブ サービス社の Outpost、グーグル...
インターネットや QQ でよく聞かれる質問は、「検索エンジンの秘密は何ですか? どのウェブサイトがウ...
【編集者注】この記事はWeibo UDCから転載したもので、著者は@沈勇有梦想です。筆者は2004年...
業界の中には、SEO は終焉を迎え、入札とブランディングの二重の圧力の下でウェブサイト最適化の役割が...
国家ポルノ及び違法出版物取締局、中国サイバースペース管理局、工業情報化部、公安部など4つの部門は4月...
記者が昨日、市公安局から得た情報によると、警察は6か月以上の綿密な捜査を経て、1日にフィッシングサイ...
[[211829]] インドはAIサービスの面では世界に追いつけないかもしれないが、仮想パーソナルア...
forwardwebは2000年に設立されたアメリカの会社で、仮想ホスティング、ドメイン名、ウェブサ...
クリプトデータセンター傘下のVPSブランド、ioncloudが6月のプロモーションを実施。サンノゼと...
世界的に有名なフルマネージド ホスティング プロバイダーである Hostdime.com は、5 月...
rfchost はシンガポール データ センターをひっそりと立ち上げました (現在、データ センター...