Scala-R統合プラットフォームでロシアのワークフローシステムをテストした方法



Skala-R監視システムのインターフェース



私たちのチームは、プライベートクラウド用のユニバーサルインフラストラクチャプラットフォームとしてSkala-Rコンバージドコンプレックスを作成しました。 仮想環境で数百のビジネスクリティカルなシステムを運ぶことができ、それらの基盤となるさまざまなテクノロジーにもかかわらず、それぞれの負荷に等しくうまく対処できるように作成しました。 すでに Habréで、「Skala-R」はSAP R / 3の負荷にうまく対応していると話しました。 ただし、大規模な組織のERPは、通常、唯一のマルチユーザーアプリケーションシステムではありません。 従来、数十のシステムを異なる負荷プロファイルを持つさまざまなプラットフォームに階層化することができ、通常はプライベートインフラストラクチャクラウドに移行する必要があります。



そのため、次のテストでは、Microsoftテクノロジに基づくロシアのドキュメント管理システムをScalaにデプロイすることにしました。これは、プラットフォームソリューションと情報処理パラダイムの両方でR / 3とは大きく異なります。





2015年7月から8月に、 IBS Interlabチームは、ドキュメント管理およびドキュメント管理システムPriority of the Docsvisionプラットフォームの Scala-Rで本格的なテストを実施しました 。 最も信頼性の高い結果を得るために、 Digital Designからこのソリューションを作成した専門家を集めました。この専門家の参加を得て、製品の最新バージョンを展開しました。 一緒に、システム内のユーザーアクションを正確にエミュレートする負荷テストを開発し、パフォーマンスインジケーターを測定しました。



どのようなシステムをテストしましたか





「Rock-R」でのCDS「Priority」のテストは、2000人以上の従業員が勤務する連邦レベルの大規模な州の機関で使用されているのと同じ構成に基づいて行われました。 テストされたシステムは、高度に専門化されたものとは言えません。開発された管理管理と明確に規制されたワークフロー手順を備えた他の大規模な州および商業構造のシステムと非常に匹敵します。 ワークフローシステムは、オプション800および1200の同時ユーザーについてテストされました。







負荷テスト回路



どのドキュメント管理システムでも、データストレージシステムとのインターフェイスで主な問題が発生します。 コンピューティングリソースとRAMの絶対および比較指標は、このようなシステムでは決して「狭い首」になることはなく、これらのリソースの需要を確実に満たすことができるため、実用的な関心はありません。 そのため、私たちのテストは、ストレージネットワークを使用した作業の評価と、従来のSANを備えた現在の生産システムの結果との比較に正確に専念しました。



まず、 Skaly-Rストレージサブシステムには2つのストレージネットワークが装備されているため、 Skaly-Rストレージサブシステムの構造について簡単に説明する価値があります。 1つ目は、コンピューティングノードの内部ディスク上に構築されたソフトウェア定義の分散アレイです。 私たちの実験では、ゲストオペレーティングシステムからのデータを保存するために使用されました。 2番目のストレージネットワークは、500および700シリーズのSkala-Rコンプレックスの一部であるクラシックディスクアレイで、アプリケーションシステムデータの保存に使用されます。 同時に、テストの目的で、単一のSAS 6Gチャネルを使用して接続されたRAID 10に搭載された7200 rpmのTB容量の10個のNL-SAS 1ディスクで単一のシェルフが使用されました。 キャッシング機能を最小限に抑えました。これにより、エンドユーザーにとっては、ストレージコストが大幅に削減され、機能が少なくなり、費用が削減されます。



32 GBのRAMを搭載したWindows Server 2008 R2を実行する2つの仮想ノードは、負荷エミュレーターとして機能しました。 800人と1200人の同時ユーザーに対して、Microsoft Visual Studio 2013で2つの異なる負荷シナリオを実行しました。 負荷シナリオの実行中に、2〜4時間以内に測定が実行されました。



運用環境のストレージネットワークは、非常に高価な西洋製のディスクアレイに実装され、1万rpmで8個のSAS 900 GBディスクが含まれていました。つまり、「Skala-R」のアレイのパフォーマンスはすでに計画中です約25〜30%低くする必要があります。







リモートワークステーション接続図



結果





テストの結果に基づいて、結果は標準操作の実行にかかった時間で取得されました。これは、同じテストを実際のインフラストラクチャで実行して得られた結果とともに、すぐに表に示します(下の表を参照)。



* システムの基本オブジェクトであるドキュメント登録カードとタスクカードの主要なパラメーターが測定されました。







800ユーザーの負荷の下でのSkala-Rスタンドでの操作の平均時間は、8ポジションのうち4ポジションで同じ負荷を持つ運用組織の生産的環境での時間を超えます。 ユーザー数を1200に増やしても、2つのコマンドを実行したときの反応時間は同じままで、他の場合は最大システムパフォーマンスに深刻な影響を与えずにわずかに変化します。 「登録カード:受信文書を登録して受信者に転送する」という操作の不一致は許容範囲内です。



完全を期すために、スタンドに取り付けて測定結果を見てみましょう。





私たちの研究により、次の結論を導き出すことができます。





そして今、より詳細に。 このテストは、すべてのユーザーの同時操作では、システムがプロセッサの推定消費電力全体を使用しないことを明確に示しました。 したがって、高価な機器の関与は非現実的であり、不必要なコストにつながります。 仮想化により、ハードウェアプラットフォームの使用効率が大幅に向上します。



高価な機器に不必要なコストをかけずに、目的のパフォーマンスを実現できます。あまり容量のないディスクで必要なストレージ容量をダイヤルするだけで十分です。 したがって、Skala-Rコンプレックスの一部として提案されているストレージサブシステムを整理するためのソリューションは、最も単純な構成でも理想的に適しています。



そして初等数学:専用ストレージと高速ディスクを備えた実稼働環境では、テラバイトのデータのコストは約2,000ドルから始まりましたが、 Scala-Rはより控えめなアレイを使用します。単一のディスクアレイ管理モジュールを使用した構成で使用した場合、米ドル。 違い:少なくとも2回。



したがって、技術的な観点からSkala-Rコンプレックスを使用することの有効性を確認しただけでなく、実際の状況では情報システムの総所有コストを大幅に削減できると主張しています。



IBSの専門家:アレクサンダーイグナティエフ、アンドレイニコラエンコ、アンドレイサングロフ、デジタルデザインの同僚:ユーリジュコヴェッツ、アンドレイカリーニン、ヴァレリーフメリニツキー、そしてDocsvisionのセルゲイクリャノフも積極的に投稿の準備に参加しました。



IBS Interlabチーム



All Articles