平均的なサーバーを選択する際に何を考慮しますか？

平均的なサーバーは、最初に考えられるよりもはるかに複雑なシステムです。インストール用のシステムを選択する場合、慎重に検討する必要がある多くの問題があります。グラスバレーのソリューションマーケティングのシニアディレクターであるマットアラードは、このトリビューンで、彼の観点から、平均的なサーバーを選択する際に考慮しなければならない重要な側面を分析します。

今日の最高の平均サーバーは、一般的なIT業界の基本的なテクノロジーを活用し、テレビ放送とビデオ制作のリアルタイム要件と高可用性のために特にこれらのテクノロジーを最適化および改善します。最高のサプライヤーは、標準のファイルシステム、ストレージ、ネットワークを使用するシステムを構築します。

これらのサプライヤーは、ITサプライヤーができない、またはしない方法で、中程度のアプリケーションのITテクノロジーの最適化と調整により、付加価値を提供します。最新のテクノロジーの実装は、より収益性の高いソリューションを生み出します。

平均的なサーバーは、さまざまな最新のテクノロジーを組み込む必要があります。これには、RAID-5またはRAID-6のトポロジに15/7.2K SASディスクを備えた8 GBファイバートランクネットワークが含まれます。ストレージコンポーネントだけでも満足のいくソリューションは提供されませんが、完全なインフラストラクチャとも統合する必要があります。 ITサーバーコンポーネントをデータブリッジとして機能させ、動的および決定論的な帯域幅要件を管理する必要があります。最適なパフォーマンスのために、64ビットとファイルシステムのオペレーティングシステムが便利です。スケーラビリティと収益性を提供する1つの方法は、10 GB/1 GBイーサネットでISCSIプロトコルを適応させて、平均的な動きの決定論的で実質的なパフォーマンスを提供することです。

帯域幅を制御するために、テクノロジーとインフラストラクチャを組み合わせる必要があります。帯域幅は、システムが機能する信頼性と、機能が提供できるものを決定する主要な要因です。サーバーシステムは、決定論的操作に必要な複数のレベルの幅レベルを管理するように設計する必要があります。これは、サービス品質メカニズムを含む共有ファイルシステムによって提供できます。

3つの帯域幅レベルを管理する必要があります。
•優先度が高い最初のレベルは、顧客が帯域幅セットを超えないように設計されているリアルタイムの平均のためです。このリアルタイムパフォーマンスは、ほとんどの通常のITシステムでは必要ないサービスレベルです。
•スペクトルのもう一方の端に、ファイル転送など、リアルタイムではない操作用に管理された共有帯域幅があります。
•これらの2つのレベルの間には、
個々のクライアントが超えられない帯域幅を割り当てられているエディションなどの重要な時間生産活動。

3つのレベルは同時に利用できる必要があります。多くのシステムでは、帯域幅管理のレベルは1つしかなく、すべてのタスクを確実に一貫して実行するために帯域幅管理に依存することはできません。

適切な平均サーバーシステムは、パフォーマンスを保証するために、冗長性、バッファリング、および複数のレベルのプロセッサを統合しています。当該システムのプロバイダーは、いくつかの生産用途のストレージパフォーマンスを特徴付け、LUN、個々のサーバー、コントローラーによる帯域幅の収量を測定します。

メディアサーバーのもう1つのユニークな側面は、ファイル管理です。ほとんどの通常のITサーバーシステムで見つかったファイルとは異なり、中型サーバーファイルは大きくなります...非常に大きいです。ストレージコントローラーやファイルシステムを含むシステムは、このタイプのファイルに対して特にタイトでなければなりません。

標準のITサーバーシステムには、迅速な読み取り/書き込みとストレージを備えた、多数の小規模でシンプルなファイルがあります。執筆プロセス中に読む必要はありません。遅延とレイテンシーは許容できます。

平均して、遅延とレイテンシーは、黒いフレームや音の損失に変換されるため、受け入れられません。平均して、大きなファイルを使用すると、ストレージには執筆プロセス中に多くの同時読み取り値があることがわかります。

適切な平均ファイル管理のために、サーバーシステムは、3月の特殊なバッファリングとプリバスカス、およびより大きなエラー修正、マルチピスタコンテンツファイルのストックコンテナ収集、および効率的かつ決定的に読み書きのためのアプリケーションレイヤーの最適化を提供する必要があります。平均生産のためにサーバーシステムを評価するとき、これは非常に批判的に検討する必要がある領域です。

メディアに適していると主張する多くのシステムは、これらの最適化を提供しないため、コンテンツの配信に必要な一定のパフォーマンスには適していません。

プラットフォームの柔軟性

平均的なサーバーは、さまざまな一意の要件に適合したさまざまなソリューションを提供できるように、多用途でなければなりません。パフォーマンスと冗長性の次元を登る必要があります。拡張能力は、複数の独立したベクトルに登る必要があります。システムは、繁殖速度の生産ニーズのために、中程度のチャネル、ストレージ容量、ファイル転送帯域幅、または運用帯域幅を増やす必要がある場合があります。
ブロードキャストサーバーとビデオ制作は、メディアサーバーとファイルサーバーとして等しく熟練している必要があります。

平均データの提供中に2回目の試行はありません。複数のレベルでの冗長性が必要です。このシステムは、メディアの顧客、メディアサーバー、ストレージ間に冗長なデータルートを提供する必要があります。これは、単一の障害点がない設計です。実装に関しては、冗長なRAIDコントローラーなどの特定のプラクティス、複数のサーバーとスイッチを介して接続されたネットワーク冗長コントローラーが利用可能でなければならないことを意味します。デバイスのレベルでは、冗長な食料源、冗長冷却、冗長な保管ユニットが必要です。

平均を相互接続するために、一部のプロセッサカードを備えた標準のPCは、信頼性や堅牢性ではありません。 24時間年中無休の環境に優れた可用性の複製と記録サービスを提供するには、この目的のために構築された放送と生産のためのデバイスを使用する必要があります。

このアプローチを使用すると、さまざまな利点を達成できます。デバイスは、モバイル環境でも使用するために強化できます。モジュラーコンポーネントにより、簡単にアクセスしてサービスが可能になります。専用のデバイスは、組み込まれた特殊なオペレーティングシステムを使用して、マルチレベルのパーソナライズされたプロセッサと汎用を使用して、信頼できるパフォーマンスを備えたユニークで複雑な特性を提供します。これらの機能には、オーディオ/ビデオ録画を管理できるマルチリレーションチャネル、オーディオ/ビデオの排出、3D左目/右目の組み合わせ、録音とビデオ排出の組み合わせ、複数/下/下/下/低変換の解像度の録音と排出量の録音と排出が含まれます。

これはすべて、低解像度のプロキシの平均の作成と管理により増加させることができます。同時に、このタイプのデバイスには、標準のストレージプラットフォーム、制御インターフェイス、グラフィックス、ネットワーク接続のすべての利点が組み込まれており、統合を促進し、コストを削減します。

平均的なサーバーシステムの不可欠な部分はストレージです。ブロードキャストと生産環境にはニーズが異なるため、サーバーシステムはさまざまなストレージソリューションを提供する必要があります。

最も単純な実装は、平均的な顧客に内部的に配置されるシリーズで接続されたSCSI（SAS）ユニットです。容量を単純に増やすために、SCSIユニットを直列に接続した外部RAIDシャーシをバスアダプターを介して平均的な顧客に接続できます。

最高の収量と柔軟性を得るには、平均的なサーバーはストレージエリアネットワーク（SAN）をサポートする必要があります。 SANは、連結ストレージへのアクセスを提供する専用のストレージネットワークです。ネットワークストレージデバイスは、オペレーティングシステムでローカルに接続されているように見えるようにサーバーにアクセスでき、ストレージディスクへの読み取り/書き込みの直接リクエストを可能にします。

サーバーコンポーネントは、イーサネットとファイバーチャネル接続の間のブリッジとして機能します。また、アプリケーションやネットワークを相互作用できるファイルの抽象化を提供するための共有ファイルシステムの席でもあります。 SANは、スケーラビリティ、接続性、帯域幅、ストレージを提供し、幅広い生産シナリオを可能にします。

サーバープラットフォームは、ファイルベースの生産に不可欠なインフラストラクチャを提供するため、相互運用性が容易で効率的になるように提供する必要がある一連の機能があります。ファイルは、直接版およびメタデータ操作のために、ディスクに基本的なフローとして保存する必要があります。他のネットワークストレージ操作、取り外し可能なサポート、編集者、ファイルと並行してインポートとエクスポートが必要です。平均ファイルは、MPEG-2、MPEG-4、DV、AVC-InTRAなどの標準的なビデオ圧縮形式をサポートする必要があります。これらのファイルは、MXFやQuickTimeなどの一般的なラッピングで交換用に利用できる必要があります。

オーディオ用のWAV、グラフィック用のQuickTime 32、Transport Video/MPEGプログラムのフローなど、他のタイプのファイルも互換性がなければなりません。ファイルは、標準のFTPプロトコルとCIFSを使用して、ならびに直接ISCSI接続を使用して転送できる必要があります。ファイルの移動プロセスを自動化するのに役立つには、サーバープラットフォームの内外でファイルを携帯するための監督フォルダーサービスが必要です。

コンテンツの所有者は、材料の再利用を希望するため、作成、保存、およびメタデータ交換は、XMLなどのオープン標準を使用してサーバーシステムによって平均ファイルに関連付けられ、管理する必要があります。

サーバーシステムとその機能の管理、および運用コストのメンテナンスと低プロパティの総コストを計画する必要があります。

システムの使用とメンテナンスを簡素化するには、システムの実装、維持、構成、更新を支援するための統合ツールと利益のセットが必要です。

アプリケーションの統合

サーバーシステムは、使用できるアプリケーションと同じくらい便利で興味深いものです。完全なソリューションを作成するには、サーバープロバイダーが使用する必要があるアプリケーションを有効にする必要があります。これらは、ライブ生産フロー、ニュース、エンターテイメント、排出物にサーバーシステムを使用できるようにするアプリケーションでなければなりません。サーバーシステムプロバイダーは、革新的で手頃な価格のソリューションを可能にするアプリケーションを作成する必要があります。

これらのアプリケーションには、摂取量、繰り返し、ビデオストレージ、エディション、チャネル制御、ブロードキャストが含まれます。アプリケーションサービスは、常にプロキシ操作、一般的な編集決定のリスト/複製リスト、一般的なメタデータとマーカーのキーワード、およびコンテンツ管理を提供する必要があります。これらの利用可能なアプリケーションを持つことは、サプライヤーが必要なソリューションが総ブロードキャストインフラストラクチャを通じて機能しなければならない複雑さの詳細を理解していることを示しています。

ユーザーエクスペリエンスとコメントは、アプリケーションの設計を強化する必要があるものです。アプリケーションは、学習曲線を削減し、それらをシンプルにすることに焦点を当てる必要があります。使いやすさも更新やメンテナンスに適用する必要があります。すべてのアプリケーションには、一般的なユーザーインターフェイスと用語が必要です。一般的なファイルの形式、プロキシ、メタデータの互換性を共有し、リスト/エディションの決定リストをリストする必要があります。

平均的なサーバープロバイダーは、生産ユーザーに必要なすべてのアプリケーションを作成できません。したがって、他のアプリケーションが第三者やエンドユーザーによって開発されるためにAPIを利用できるようにする必要があります。 APIは、独自の言語を必要としない一般的なプログラミング環境に耐える必要があります。

La capacidad tradicional de una API es para el control del canal de media. Con la transición a la producción basada en archivos, la API también debe incorporar las capacidades de gestión de contenidos. La API debe proporcionar acceso directo a los activos de media. Se debería poder acceder a través de servicios de red para todo el sistema de activos con la capacidad de iniciar la transferencia de archivos a través de protocolos FTP y CIFS. Todas las nuevas funcionalidades se deben soportar abiertamente a través de la API. Para crear estructuras de aplicación sofisticados, debe haber una API que soporte una capa de abstracción de arquitectura orientada a servicios (SOA) para proporcionar servicios de gestión de contenidos, proxy, ingesta, emisión, búsqueda, transferencia y metadatos.

よく実行されたAPIを使用すると、平均的なサーバープロバイダーには、アクティブな開発者の多様なコミュニティを促進するために、開発サポートエンジニアのチームが必要です。彼らは、サプライヤーが幅広いサポートアプリケーションを開発するのを支援します。

テストと検証

平均的なサーバーがこれらすべての機能と統合を提供するためには、ソリューションが提供されるずっと前に、広範な研究開発作業を実施する必要があります。エンジニアリングレベルでの慎重なソフトウェアとハードウェア設計の開発が予想されますが、組み込む必要がある他の重要な技術プロセスもいくつかあります。

さまざまな標準ITコンポーネントとサブシステムを密接に統合することを目的としているため、厳密な検証を実行する必要があります。

検証の一部として含める必要があるテクノロジー評価基準の一部：
•特定のテクノロジーは、その特性と仕様においてどのような約束を満たしていますか？
•計画されたアプリケーションに技術を効果的に使用できますか？
•テクノロジーは、システム全体の基本的な柱としても機能しますか？
•テクノロジーを統合するための開発サイクルは予測可能ですか？
•テクノロジーは予想通りに上昇し、さまざまな負荷の下で動作しますか？
•エラー条件での運用行動はどうなりますか？

ストレージ検証の評価基準の一部には、以下を含める必要があります。
•再構築中、およびさまざまなサーバー入力および出力構成の実行中の数日間の比較パフォーマンス評価
•レイテンシと比較したパフォーマンスと比較した価格
•特定の期間内に応答するストレージサブシステムを増やしたレイテンシを区切りました
•全負荷でストレージコントローラーを交換し、ライブファームウェアの更新を全負荷にします
ファイルシステムの検証に関する評価基準の一部には、以下を含める必要があります。
•SAN共有を使用すると、の同時アクセスへのアクセスはどのようにアクセスできますか
リアルタイムで、実際のアプリケーションではありませんか？
•24時間年中無休で操作しても、解体が必要ないように、自動ファイルシステムプロファイル管理
ネットワークデータの動きを検証するための評価基準の一部には、以下を含める必要があります。
•ネットワークデータとデータ構造の管理。そのため、転送は不当に損失なしになります
•イニシエーターの特性評価、構成、管理、デバイス、ネットワークインターフェイスカード、ネットワークスイッチの目標により、クリーンエンドからエンドの損失なしでクリーンな接続として機能するように
•ネットワークスイッチ、ポート構成、マイクロコードバージョンの内部アーキテクチャの分析

設計が完了してソフトウェアが作成されたら、コンポーネント検証/マルチエタパシステムとテストプロセスを完了する必要があります。このプロセスは、長期ベースに実装され、非常にスケーラブルである必要があります。継続的なサポートと新しいバージョン、各テクノロジーの機能と動作、およびシステム全体の動作には、広範な回帰テストが必要です。
A medida que avanza la tecnología, habrá generaciones siguientes de componentes. A medida que se incorporan, el sistema debe ser testado de nuevo con las versiones nuevas de las unidades de almacenamiento, controladores RAID, sistema de archivos, servidores de datos, tarjetas de interfaz de red, adaptadores de bus host, y conmutadores, para asegurar que el sistema se comporta como está especificado.

Para poner el esfuerzo necesario en perspectiva aquí hay algunos ejemplos de lo que normalmente se debe hacer con cada generación de componentes para garantizar el funcionamiento del sistema.
– Almacenamiento RAID:
平均的なサーバーシステムサプライヤーの2人のエンジニアとサプライヤーの3人のエンジニアが検証する6か月。ファームウェアバージョン、回帰テスト、品質制御、構成ツールの分析の3か月。
- 共有ストレージユニットのシリーズ：
ファームウェア、検証、テストを開発するための2人のエンジニアと4〜6か月。検証の一部は、数年間拡張サービスを対象としているため、将来の世代のユニットでストレージを拡張し、ユニット、ユニットグループ、計画されたパフォーマンスレベル内のすべての作業を再構築することができます。
- 一連の内部ユニット：
ファームウェア、検証、テストを開発するための2人のエンジニアと4〜6か月。パフォーマンスと検証分析、障害分析、平均の使用、管理の統合、容易なツールの使用のためのページの特別な管理。共有ユニットと同様に、ユニットまたはユニットのサプライヤーのすべてのファミリが必要な基準を満たしているわけではありません。
- メディアネットワーク：
長年の最初の開発の後、3人のエンジニアが9か月間、10ギガビット、比較パフォーマンス評価、障害分析、サプライヤーの要件、統合に基づいて最新の平均ネットワークツールを開発しました。 6か月のリリーステスト、構成ツールのスケール、分析。

サービスとサポート

メディアサーバーが選択された後、サプライヤーとの対話は
新しいフェーズを入力します。現在、サプライヤーは、ビジネスニーズを満たすシステムを効果的に設計および実装するために、サービスの経験を実装する必要があります。これらの分野のサプライヤーの評価は、新しいテクノロジーの利点を知覚し、リスクを最小限に抑え、総資産コストを管理するために不可欠です。

効果的なシステムの設計は、技術のすべての利点を知覚するために不可欠です
メディアサーバー。このステップでは、サプライヤーシステムアーキテクトは、詳細な技術的要件を満たすために発見プロセスに参加し、システム設計でそれらの要件を翻訳する必要があります。経験豊富なシステムアーキテクトは、優先ビットの圧縮と速度、推定量のストレージ、摂取量とチャネルの排出量など、お客様のニーズについて基本的な質問をします。

クラスの最高のサプライヤーに対する本物のアドバイザリーアプローチは、システムの将来の潜在的な拡大、他の企業システムとのインターフェースポイント、長期データの継続性計画、およびシステム障害に対する完全な耐性を調査する必要があります。これらの考慮事項は、設計プロセスに加えて、単純なビット、バイト、およびチャネルデータに影響を与える必要があります。

効果的なシステム設計がビジョンである場合、サイト上のシステムの実装中に現実が構築されます。ここでは、メディアサーバーサプライヤー、フィールドサービスエンジニア、トレーナーのプロジェクトマネージャーのチームが組み合わせて、実際の環境で新しいシステムを委託します。システムは最適なパフォーマンスを設定してテストする必要があり、その後、ユーザーは操作手順とメンテナンス手順でトレーニングを受ける必要があります。

各平均的なサーバープロバイダーには、これらの基本的な機能が必要です。複雑さとサイズのシステムの場合、このような基本的な実装機能は、プロジェクト制御、スケジュール、リスクに関する詳細なプロジェクト管理方法論によって調整されなければなりません。

サプライヤーの評価プロセスでは、各サプライヤーは、作業宣言、プロジェクトプログラミング、サプライヤー/ベンダー間のコミュニケーション、システムドキュメント、および問題の監視など、プロジェクト管理方法論を説明するよう求められなければなりません。

適切に設計および実装された平均サーバーシステムは、さまざまな平均配信インフラストラクチャの中心など、長年の操作を提供できます。ただし、必然的に、すべてのシステムでは、問題を解決し、互換性のあるソフトウェアバージョンで更新されたシステムを維持し、欠陥のあるハードウェアコンポーネントを置き換え、システム操作の一般的なメンテナンスを行うためのテクニカルサポートが必要です。潜在的なサプライヤーは、資本投資が保護されるように、これらの重要な分野への能力と投資を実証する必要があります。

基本的なテクニカルサポート機能を超えて、高度なカスタマーサービスインフラストラクチャを備えたミディアムサーバーサプライヤーは、次のような高可用性サービスを提供できるはずです。
•電話による24時間年中無休のテクニカルサポート
•リモートシステム診断
•ソフトウェアの起動と関連するインストールサービスへの継続的なアクセス
•翌営業日への配達に伴う高度なハードウェア交換
•フィールドサービスエンジニアリング

このような高可用性サービスを提供できるメディアサーバーサプライヤーは、企業全体、大気排出、オンライン運用の平均資産の収益性の流れを保証しながら、システムの不活性時間を大幅に削減できます。

さらに、最初のレベルのカスタマーサポート組織は、排他的な技術アカウント管理、24時間365日のリモート監視システム、エンジニアリングサポートなど、外部でさえ密接な関係サービスを提供できます。

多くの場合、これらのサービスは、応答時間パラメーターで確立されたシステムへのサポート契約のコンテキストで提供されます。サポート契約は、特定のレベルのパフォーマンスでシステムサプライヤーを強制するだけでなく、確実に資産コストを制御します。可能なメディアサーバーのサプライヤーの完全な評価には、カスタマーサービス、高可用性サービス、およびシステムサポート契約のレビューを含める必要があります。