🏌️ 🧑🏿 ⛳️ 手動テストでのXenServerおよびその他の無料/オープンソースの使用 📄 🍭 👎

私たちのテスト部門でXenServerがどのように定着したかについて、また別の使用済みフリー/オープンソース（DRBL + Clonezilla、テープリダイレクタ、MHVTL）について少しお話したいと思います。選択は、イデオロギー上のこれらの製品に基づいていませんでしたが、純粋に実用的な理由-それらは便利で拡張可能です。しかし、この記事では注意を払う多くの問題があります。
カットの下に多くのテキストと画像。

ユーザーサポート部門のアクロニステストチームで働いており、ユーザーの問題を再現しています。ディスク環境とハードウェアのシミュレーションから始まり、ソフトウェアとその特定の設定で終わります。タスクは、2つのワークステーションを使用してテストベンチの動作を保証することでした。 ESXi、Hyper-V、Proxmoxなどが試されましたが、それでもXenServerの使用に落ち着きました。そして、これはそれから来たものです。

ハードウェア

最初は、XenServer 4.2がインストールされたディスクが1つありました。最初は、速度は良好でした。少し後に、2人がサーバーの使用を開始しました。すでに困難な環境がありました（たとえば、負荷がかかると常に動作する300GBデータベースを備えたExchange 2003など）。長時間ロードされた仮想マシン（および1台のサーバーで平均20個を同時に実行）で、IO待機が数秒に達することがよくありました。何かをする必要がありました。

最初に思いついたのはRAIDでしたが、実装が速くなく、昨日ソリューションが必要でした。そのとき、ZFSがDebianリポジトリに追加され、試してみることにしました。

2つのワークステーションにはそれぞれ、4つのSATA2ポート、16 GBのRAM、およびギガビットネットワークカードを備えたマザーボードがあります。
最初のマシンはハイパーバイザー専用で、USBフラッシュドライブからロードされました。
サーバーUbuntu 11.04が2番目のマシンにインストールされ、ZFSが機能するために必要なすべてのパッケージがインストールされました。 4reディスクをそれぞれ1 TBずつインストールしました。 RAID 10が選択されたマザーボードにはSATAポートが4つしかないため、OSはUSBフラッシュドライブにもインストールされます。
ハイパーバイザー自体は、ギガビットスイッチを介してZFSに接続されます。
実験が行われ、記事が読まれ、その結果、ZFSでGZIP圧縮のサポートがオンになり、チェックサム検証がオフになり、重複排除も拒否されました。これが最も最適なソリューションであることが判明し、8つのコアすべてが100％でロードされることはほとんどなく、十分なメモリがあります。残念ながら、SSDでキャッシュをテストできませんでした:)

ファイルシステム自体はNFSを介して外部にエクスポートされ、ZFS自体によってネイティブにサポートされます。また、XenServer、およびESXはNFSリポジトリと連携します。これにより、2台のXenServerと3台のESXiで同じストレージを同時に使用できました。 Hyper-Vはこのシリーズからノックアウトされ、en望の永続性を備え、Server 2012ではNFSの使用を拒否しますが、これはMSの良心によるものです。

構成されたZFSは次のようになります。

root@xenzfs:~# zpool status pool: xen state: ONLINE config: NAME STATE READ WRITE CKSUM xen ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 sda ONLINE 0 0 0 sdb ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 sdc ONLINE 0 0 0 sdd ONLINE 0 0 0 errors: No known data errors

 root@xenzfs:~# zpool list xen NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT xen 1.81T 1.57T 245G 86% 1.00x ONLINE -

ディスクへの書き込み速度は、1つのディスクの速度の約2倍に相当します。

現在、最大40台の仮想マシンがパフォーマンスの問題なしに同時に動作しますが、20台のマシンの前はIOWが最大5秒低下していました。現在、ZFSの発売から1年半後、ソリューションは信頼性が高く、高速で、非常に予算に優しいと見なすことができます。ストレージ上のNFSおよびCIFSサーバーを上げて、他の目的に使用できるようにします。
XenServerでは、CIFSネットワークドライブ上にISOストレージを作成できます。リリーステスト前の製品はISOイメージ（ローカライズの異なるWindowsとLinuxのインストーラー）に組み込まれ、内部ギガビットネットワークのネットワークドライブにダウンロードされます。その結果、マウスを1回クリックするだけで（主観的には、XenCenterはvSphereよりもはるかに便利で高速です）またはスクリプトを使用して、このISOを仮想CDROMに挿入し（同時に数十台のマシンを使用できます）、製品を直接「ディスクから」配置し、時間を節約します大きな（2GB +）ファイルをコピーします。もちろん、このような線形読み取りは、特にインストールが5台以上のマシンから直接行われる場合、ネットワークを介して行われますが、それでも非常に便利です。

ストレージが接続されているギガビットネットワークは、仮想マシンでも使用できます。したがって、他のすべてのテストにCIFSを使用できます。便宜上、DHCPサーバーもZFSマシンで作成されました。

仮想マシンに加えて、通常のワークステーションでテストする必要があります。これは、テープドライブとすべての種類のREV、RDXディスクなどでテストしています。マシンにさまざまな環境を絶えず迅速に展開する必要があります。 ESXハイパーバイザーでも、Hyper-Vを搭載したWindows 2008R2でも、iSCSIマルチパスを強化したSLESでも。この目的のために、 DRBLが使用されます。

DRBLとClonezillaを組み合わせることで、柔軟なスクリプトを使用してPXEを介してイメージを迅速に展開でき、すでに展開されているマシンのNATサーバーとしても機能します。

内部ネットワーク上のマシンは、NATを介して外部ネットワークにアクセスし、それら自体はRDPを介してiptablesを介してアクセスされます。

 iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3390 -j DNAT --to 192.168.1.50:3389 iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3391 -j DNAT --to 192.168.1.51:3389 iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3392 -j DNAT --to 192.168.1.52:3389

さまざまなテープドライブのセットが、無料のテープリダイレクターを使用する1台のマシンに接続されているため、仮想マシンはiSCSIを介してそれらを使用できます。 MHVTLを上げた別の仮想マシンもありますが、ハードウェアドライブも必要です。すべての問題がVTLに現れるわけではありません。

展開/クローン作成は、Perl + GTKで作成されたユーティリティを使用して2回クリックするだけで実行されます。それは非常に簡単に動作します-ブロックからのコマンドはコンパイルされ、SSHを介して実行されます。気にしないで、リポジトリはここにあります。コードは未加工ですが、 github.com / Pugnator / GTKdrblを実行しています

インターフェース

主観的に便利なインターフェイスはCitrix-XenCenterによってのみ提供されますが、残念なことにWindows専用です。さらに、何らかの理由で、重要で便利な機能がインターフェイスに表示されませんでした。たとえば、仮想マシンを一時停止する機能や、残念ながら、仮想マシンが固くハングしたときに頻繁に必要なXAPI再起動オプションなどです。

sourceforge.net/projects/openxenmanagerなどの他のオプションがありますが、それらは十分に安定していないことが判明しました。

VNC Webプロキシwww.xvpsource.orgがあります

便利ですが、ブラウザに含まれているJavaが必要です（問題があります）。まず、VNCの場合、完全なインターフェースで作業することはできません。

その結果、Linux用のクライアントはGTK3で作成され、Webでも使用できます。 GTK Broadwayを使用すると、ブラウザでHTML5 + WebSocketsを介してこのようなツールを取得できます

このテクノロジーでは、多くのユーザーが同時に使用することはできませんが、LinuxとWebの両方で完全に作業でき、起動パラメーターを変更するだけです（たとえば、2つのアイコンに移動します）。

HTML5フロントエンドを使用する場合、アプリケーション自体に多くの制限が課せられ、何らかの理由でこれらの制限は文書化されていません。制限の例としては、トレイアイコンを使用できない、相対的なウィンドウの配置などがあります。結果は、不安定な動作から転倒までです。
3年前の説明ページとニュースを除けば、ブロードウェイには何もないので、現在のところ、ブロードウェイの勉強はGTK3ソースコードを読んでいます。

API

C、C＃、Java、Python、およびPowershell用のAPIが存在します。 Cの場合、アセンブリはLinux専用ですが、ソースを少し改良する方法により（当時はmingwに何らかの機能の実装はありませんでした）、すべてがWindows（MinGW）で正常にアセンブルされました。 APIはHTTP（S）を介して機能します。 APIは、仮想マシンへのかなり低レベルのアクセスを提供します。

ディスク

マウスでクリックしてMBRをすばやく表示することから、仮想マシンからファイルを抽出するか、オフになっている仮想マシンにファイルをダウンロードすることまで、多くのことが必要でした。
これは、たとえばBSODの場合に必要になることがあります-レジストリを抽出する（および/または編集して、たとえばドライバーをオフにする）、またはブートローダーオプションを編集する（シリアルポート経由でデバッグを有効にする）など。そのような目的のために、ブートディスクの助けに頼らなければなりません。
ただし、そうでない場合もあります。XVA形式のHTTP GETを介して仮想マシンをエクスポートすることができます。これは、ディスクブロックが内部にあるTARアーカイブです。

 $ tar -tvf test.xva
 ---------- 0/0 17391 1970-01-01 01:00 ova.xml
 ---------- 0/0 1048576 1970-01-01 01:00 Ref：946/00000000
 ---------- 0/0 40 1970-01-01 01:00 Ref：946 / 00000000.checksum
 ---------- 0/0 1048576 1970-01-01 01:00 Ref：946/00000007
 ---------- 0/0 40 1970-01-01 01:00 Ref：946 / 00000007.checksum
 ---------- 0/0 1048576 1970-01-01 01:00 Ref：949/00000000
 ---------- 0/0 40 1970-01-01 01:00 Ref：949 / 00000000.checksum
 ---------- 0/0 1048576 1970-01-01 01:00 Ref：949/00000003
 ---------- 0/0 40 1970-01-01 01:00 Ref：949 / 00000003.checksum

このアーカイブをその場で読むと、目的のMBRを簡単に取得でき、パーティションのオフセットとタイプを読み取った後、ファイルを読み取ることができます。ただし、現時点では、MBR抽出のみが実装されています。バージョンXenServer 6.2以降では、RAWディスクをエクスポートできます。 XenServerの将来のバージョンでは、任意のオフセットからディスクのデルタのみをエクスポートする機能を導入することを約束しており、これにより新しい可能性が開かれます。

ネットワーク

さまざまな方法で、仮想マシンネットワークでの作業を制御できます。これは通常、仮想マシンにインストールされているwireshark / tcpdumpです。目的のダンプが収集され、調査のために別の場所に転送されます。しかし、より良い方法があります -実行中の各仮想マシンには独自のdom-idがあり、それに応じて、ハイパーバイザーからアクセス可能なvifDOMID.0という形式のVIFデバイスもあります。 SSHを介してハイパーバイザーに接続することにより、任意のスイッチオン仮想マシンのダンプを簡単に取得できます（もちろん、ネットワークカードが追加されています）。さらに、 Q＆Aからのアドバイスによると、プログラムはパイプを作成してWiresharkを起動します。そして、リアルタイムでトラフィックを取得/フィルタリングします。

ゲストツールとシリアルポート

APIは、ファイルのコピーなど、vix vmWareのゲスト操作に類似した機能を提供しません。
メインソフトウェアのインストールで、ギガビットネットワークでISOを使用して問題を解決した場合、コマンドの転送/ロギング、データの表示では、すべてがそれほどスムーズではありません。中間ネットワークドライブを使用する必要があり、これが常に可能であるとは限りません（テスト条件、分離されたネットワーク）。いずれにせよ、それは時間がかかり、不便です。

最初に思いついたのは、仮想シリアルポートを使用することでした。 TCP経由でXenServerを使用してブロードキャストされる仮想COMポートをアクティブ化できます。これで、対応するアドレスで接続が開いている場合、115200の速度でメッセージを送受信できます。仮想プログラム「シリアルポートCLIプロキシ」が仮想マシンで起動され、シリアルポートからのコマンドの変換が実行され、結果が返されます。
落とし穴がいくつかありました。
1）クライアント（仮想マシン）がこの間に少なくとも1バイトを送信しなかった場合、転送された65535バイトに達すると、送信が中断されます。
2）ポートの有効化は、再起動後にのみ機能します。つまり、オフにした仮想マシンでオンにするか、再起動する必要があります。
3）何らかの理由で接続が切断された場合、再起動する前に接続を復元する方法はありません。
4）最悪の部分は、TCPサーバーが応答しない場合、起動時に仮想マシンがフリーズすることです。

これらの理由により、たとえばxenstoreを介して、他のメソッドが並行して検索されました。これは、さまざまなドメインで利用可能なリポジトリです。仮想マシンを含む。 2メガバイトのオーダーのバッファーがあり、非常に高速に記録されます。ただし、読み取りは115200より遅く、インストールされたxenツールが必要であり（常に可能とは限りません）、慎重にコードをテストする必要があります。たとえば、ドライバーソースのコメントから判断して、 XENSTORE_PAYLOAD_MAXを超える書き込みを行う場合、これは致命的です。

現時点では、仮想マシンの準仮想シリアルポートをハイパーバイザーへのsshトンネル経由で使用することを考えています。これは、ネットワークカードに関する上記の方法と同様です。どうやら、これは最も安全で最速の方法です。現時点では、これが実現可能であることが確認されています。

まったく同じ方法で、TCP / SSHを介してシリアルポートを転送することでWindows / Linuxカーネルをデバッグできます。たとえば、WinDbgは既にパイプを介してローカルに接続されています。そのような目的のために、 Windowsのすべての利用可能なバージョンの文字のセットを備えた別個の仮想マシンが作成されました。

おわりに

XenServer APIを使用して調査し、オープンソースの長所と短所の多くを経験しました。十分な機会は弱い文書にかかっています。 VIXが非常に詳細に記述されている場合、同じxenserver api-3つの例、4つのテストファイル、およびソースヘッダーのコメントを使用します。コードは理解できますが、個々の機能をどのように接続するかは、開発者またはXenのアーキテクチャを熟知している人にとって明らかです。たとえば、ディスクサイズを調べるなどのタスクはどこにも記述されていません。そして、アーキテクチャを知らない-推測はあまり簡単ではありません。もちろん、Xenの構造を掘り下げ、掘り下げていくうちに、ずっと明確になりました。しかし、私は多くの質問への回答を得ませんでした、そして週末のIRCチャットで誰も答えません-孤独な訪問者は「今日は日曜日です」と書いています:)。
しかし、一年の間にウィキ、記事、例が追加され、新機能のデモンストレーションが行われ、進歩があります。将来、XenServerがサードパーティソフトウェアの優れたセットを使用して市場で強力なプレーヤーになることを本当に期待しています。

手動テストでのXenServerおよびその他の無料/オープンソースの使用