翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS Elemental MediaLive Anywhere のセットアップ
AWS Elemental MediaLive Anywhere をデプロイする予定がある場合は、このセクションをお読みください。これにより、組織のデータセンターにあるオンプレミスハードウェアで MediaLive チャネルを実行できます。MediaLive チャネルには、標準の MediaLive 入力を含めることができますが、MediaLive Anywhere にのみ適用される SDI 入力などの入力を含めることもできます。
このセクションでは、オンプレミスノードを組織のネットワークに統合する方法と、ネットワークに接続されたクラスターにノードを整理するように MediaLive Anywhere を設定する方法について説明します。
MediaLive Anywhere は、共有責任モデルを使用します。実行中のチャネルと公開されたログとメトリクスの忠実度を保護するために、ノードへのアクセスを保護する責任があります。AWS は、エンコーディングトラフィックを管理し、ソフトウェアの継続的なアップグレードを含むソフトウェアを管理する責任があります。責任共有モデルの詳細については、「[のセキュリティ AWS Elemental MediaLive](security.md)」を参照してください。
# MediaLive Anywhere の仕組み
AWS Elemental MediaLive Anywhere のデプロイには、いくつかのコンポーネントが含まれます。
+ 組織内のネットワーク。これらのネットワークは、次の図の青いボックスで表されます。
+ クラスター (ブルーボックス）。チャネルプレイスメントグループ、ノード、チャネルをグループ化します。
+ ノードハードウェアを表すノード (緑色のボックス）。通常、デプロイには、ピークチャネル負荷を処理するのに十分なノードに加えて、ノードの回復性のためのいくつかのバックアップノードが含まれます。
+ チャネルプレイスメントグループ (黄色のボックス）、どのチャネルをグループ化するか。
+ MediaLive Anywhere ノードで特に実行される MediaLive チャネルであるチャネル (オレンジ色のボックス）。
![\[Hierarchical diagram showing multiple levels of interconnected components in a system architecture.\]](http://docs.aws.amazon.com/ja_jp/medialive/latest/ug/images/anywhere_cluster_relational.png)
クラスターはノードのコレクションです。クラスターは 1 つ以上のネットワークに関連付けられています。
各クラスター内には、ノード、チャネルプレイスメントグループ、およびチャネルがあります。
## MediaLive Anywhere クラスターのプロビジョニング
MediaLive Anywhere をプロビジョニングするときは、次の接続を設定します。
+ クラスターには 1 つ以上のノード (緑色のボックス) が含まれています。1 つのクラスターでは、すべてのノードに同じ処理機能と、同じネットワークインターフェイスと SDI インターフェイスがあります。ノードは 1 つのクラスターに属します。
+ チャネルプレイスメントグループ (黄色のボックス) は、チャネルのコレクションです。チャネルはチャネルプレイスメントグループに属します。
+ チャネルプレイスメントグループをノードにアタッチします。クラスターが本番環境にある場合、ビデオエンジニアはチャネル (オレンジ色のボックス) を作成し、それぞれを特定のチャネルプレイスメントグループにアタッチします。
ノードはすべて交換可能です。どのノードでも、クラスター内の任意のチャネルプレイスメントグループのチャネルをエンコードできます。
## 実行時の MediaLive Anywhere
MediaLive ビデオエンジニアがチャンネルを設計するとき、チャンネルのクラスターとクラスター内のチャンネルプレイスメントグループを指定します。ビデオエンジニアは、クラスターとチャネルプレイスメントグループを慎重に選択します。これはアドホックな決定ではありません。
MediaLive オペレータがチャネルプレイスメントグループの最初のチャネルを実行すると、MediaLive はクラスター内の空きノードを選択してチャネルを実行します。その後、チャネルプレイスメントグループの別のチャネルが起動するたびに、そのノードで常に実行されます。
# クラスターの設計
このセクションでは、MediaLive Anywhere ワークフローの設計を担当するビデオエンジニアを対象としています。クラスターを設計し、MediaLive Anywhere ノードを組織のネットワークに接続する責任を負うネットワークエンジニアに情報を提供する必要があります。
## チャネルを評価する
1. 作成する MediaLive チャネルのエンコード要件を特定します。
1. SDI 接続の観点から、各チャネルのノードハードウェア要件を特定します。例えば、チャネルには SDI クアッドリンク接続が必要になる場合があります。
1. 各チャンネルに必要な処理能力とメモリを評価します。MediaLive Anywhere チャネルはすべて単一パイプラインチャネルであることに注意してください。
## チャネルをグループ化する
1. 同じノードハードウェア要件に基づいて、チャネルをグループに整理します。
1. 次に、これらのサブグループを分割して、1 つのノードが一度に実行するチャネルの最大数の処理能力とメモリ需要を処理できるようにします。アクティブなチャネルの数によってノードが過負荷にならないようにする必要があります。
1. 各サブグループは*チャネルプレイスメントグループ *です。
各ノードは 1 つのチャネルプレイスメントグループを処理します。各チャネルプレイスメントグループは、特定のチャネルセットを処理します。グループをクラスターに整理する
## グループをクラスターに整理する
1. デプロイに必要なノードの数を特定します。この数は、繁忙期におけるチャネルプレイスメントグループの数に等しくなります。つまり、同時に処理できるチャネルプレイスメントグループの最大数です。
これらのノードは、アクティブなノードの*クラスター*に収集されます。
1. 各クラスターに必要なバックアップノードの数を決定します。この決定はリスク評価演習です。極端な場合、アクティブなノードごとに 1 つのバックアップを決定できます。一方、すべてのアクティブなノードを処理するバックアップを 1 つ特定できます。
これで、アクティブノードとバックアップノードのクラスターができました。
次の図は、MediaLive Anywhere クラスターの設計の可能性を示しています。
CL はクラスターの略です。Nd は node の略です。CPG は、チャネルプレイスメントグループの略です。オレンジ色のボックスはチャネルです。
![\[Diagram showing two clusters with nodes and channel placement groups containing channels.\]](http://docs.aws.amazon.com/ja_jp/medialive/latest/ug/images/anywhere_cluster_cnp.png)
この図では、2 つのクラスターがあります。どちらのクラスターも同じ 2 つのネットワークに関連付けられています。
+ Cl-A には、3 つのアクティブなノードと 1 つのバックアップノード (Nd-4) があります。すべてのノードには、同じ処理能力、メモリ、物理インターフェイスがあります。
Cl-A には、3 つのチャネルプレイスメントグループもあります。各チャネルプレイスメントグループに関連付けられたチャネルがあります。任意のチャネルプレイスメントグループの 1 つ以上のチャネルは、クラスター内の任意のノードで実行できます。2 つのチャネルプレイスメントグループを同じノードで同時に実行することはできません。1 つのノードは、1 つのチャネルプレイスメントグループ内のすべてのチャネルを同時に実行できます。ただし、各チャンネルは個別に開始することに注意してください。
+ Cl-B には、アクティブなノードが 1 つ、バックアップノードが 1 つあります。
Cl-B には、チャネルプレイスメントグループが 1 つだけ、チャネルが 1 つだけあります。これは処理要求の高いチャネルであり、独自のノードハードウェアが必要になる可能性があります。つまり、別のクラスターに属しています。許容されます。チャネルプレイスメントグループに複数のチャネルがアタッチされている必要があるというルールはありません。クラスターには、その単一チャネルに対してアクティブなノードが 1 つだけあります。
# ネットワークリソースの特定
このセクションでは、MediaLive Anywhere ノードを組織のネットワークに接続する責任を負うネットワークエンジニアを対象としています。ネットワークエンジニアは、MediaLive Anywhere チャンネルを設計するビデオエンジニアと相談してこれらのタスクを実行します。
ビデオエンジニアが識別したクラスターごとに、以下のステップに従います。
**Topics**
+ [ネットワークを特定する](#emla-identify-networks)
+ [CIDRs](#emla-reserve-cidrs)
+ [ルートを特定する](#emla-identify-routes)
+ [デフォルトルートを特定する](#emla-identify-default-route)
+ [データの概要](#emla-deploy-requirements-summary)
## ネットワークを特定する
クラスターごとに少なくとも 1 つのネットワークを特定します。必要なネットワークの数は、トラフィックに対してネットワークが従うルールによって異なります。MediaLive Anywhere トラフィックを処理する一般的な方法は次のとおりです。
+ MediaLive Anywhere 管理用の 1 つのネットワーク。
+ ノードへのすべてのプッシュ入力に 1 つのネットワーク。
+ ノードからのすべての出力に 1 つのネットワーク。
クラスターごとに個別のネットワークを識別する必要はありません。すべてのクラスターで同じタイプのトラフィック (入力トラフィックなど) が同じネットワークを通過できます。
## CIDRs
クラスター内のノード用に予約する IP アドレスの数を計算できるように、ビデオエンジニアから情報を提供する必要があります。
+ クラスター内のすべてのチャネルのプッシュ入力の総数。MediaLive Anywhere は、各プッシュ入力に IP アドレスを割り当てます。
+ すべてのチャネルのすべての出力グループの出力の合計数。出力の数が必要です。これは出力グループの数を超える可能性があります。MediaLive Anywhere は、これらの出力のソース IP アドレスを割り当てます。
各ネットワークで、これらの IP アドレス用に 1 つ以上の CIDR ブロックを予約します。プッシュ入力と出力が同じネットワーク上にあるようにネットワークが設定されている場合、2 つのタイプのトラフィックが同じプールを共有することに注意してください。
## ルートを特定する
MediaLive Anywhere は、ノードインターフェイスから最初にホップし、ノードインターフェイスに最後にホップするすべてのルートに関する情報で設定する必要があります。
これらのルートをビデオエンジニアに提供します。ルートを CIDR ブロックとゲートウェイ (該当する場合) として指定します。
## デフォルトルートを特定する
ノードとの間で送受信されるトラフィックのデフォルトルートとして、いずれかのルートを特定します。MediaLive Anywhere は、トラフィックの送信先がどのネットワークのルートテーブルでもカバーされていない場合、このデフォルトを使用します。
## データの概要
以下は、クラスターごとに収集すべき情報の概要です。MediaLive Anywhere を設定するユーザーにこの情報を提供します。
****
| データ | MediaLive Anywhere でこのデータをセットアップする場所 |
| --- | --- |
| このクラスターのネットワーク数と各ネットワークの目的 | ネットワークの作成時 |
| 各ネットワークで、MediaLive Anywhere 用に予約する CIDR ブロックのリスト | ネットワークの作成時 |
| 各ネットワークのルート | ネットワークの作成時 |
| ノード上の各ネットワークインターフェイスについて、次の情報セットがあります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/medialive/latest/ug/emla-deploy-identify-network-requirements.html) | ノードを作成するとき |
| クラスター上のすべてのノードのデフォルトルート | クラスター作成時 |
| クラスター内の各ノードの初期ロール (アクティブまたはバックアップ） | ノードを作成するとき |
# ノードインターフェイスのマッピングの設計
このセクションでは、MediaLive Anywhere ワークフローの設計を担当するビデオエンジニアを対象としています。
各クラスターで、マッピングのコレクションを設計する必要があります。これらのマッピングは、[ネットワークを特定](emla-deploy-identify-network-requirements.md#emla-identify-networks)してクラスターを設計した後に設計する必要があります。エンコーダートラフィックを処理するネットワークごとにマッピングを決定する必要があります。管理ネットワークのマッピングを作成する必要はありません。
## インターフェイスマッピングについて
各マッピングは、1 つのネットワークを、そのネットワークのトラフィックを処理するノードネットワークインターフェイスに接続します。例えば、入力トラフィックのノードネットワークインターフェイスに入力ネットワークを接続するマッピングがあるとします。
![\[Diagram showing a Network box connected to a Node box, each with a single component.\]](http://docs.aws.amazon.com/ja_jp/medialive/latest/ug/images/anywhere_nwork_nodeinterface.png)
マッピングは、次の図に示すように機能します。マッピング (青いボックス) は、割り当てるネットワーク ID と論理インターフェイス名の 2 つの情報で構成されます。マッピングは、ネットワーク (ピンク色のボックス) を物理インターフェイス (黄色のボックス) に接続します。
![\[Diagram showing network, mapping, and node components connected in a linear flow.\]](http://docs.aws.amazon.com/ja_jp/medialive/latest/ug/images/anywhere_nwork_full.png)
クラスター内のネットワークごとに 1 つのマッピングを設計する必要があります。ノードごとに 1 つのマッピングを作成しません。代わりに、すべてのノードの同様の物理インターフェイスが同じマッピングを共有します。たとえば、入力トラフィックの物理インターフェイスはすべて同じマッピングを共有します。
## マッピングを設計する手順
クラスターにマッピングを作成します (上の図の青いボックス）。次に、各ノード (各緑色のボックス) に、各論理インターフェイス名を適切なノードインターフェイスに割り当てる 2 番目のマッピングを作成します。
1. ネットワークに名前を割り当てます (上のピンク色のボックス）。
1. 各ネットワークの論理インターフェイスに名前を割り当てます (上の灰色のボックス）。
名前フィールドでは大文字と小文字が区別されることに注意してください。これらの名前のリストを作成し、後でネットワークと論理インターフェイス名を作成するときは、これらの正確な名前を使用してください。
1. ネットワークを各ノードの対応する物理インターフェイスに一致させます。名前は、古いスタイル (Eth1 など) または新しいスタイル (eno5555 など) です。
通常、インターフェイスの位置はすべてのノードで同じです。ただし、それらは異なる場合があります。以下の例では、CL-A でノード 3 は Eth2 と Eth3 を使用します。
1. クラスターごとにこれらのステップを繰り返します。
最後に次のようなリストが表示されます。このリストでは、 に示されているクラスターとノードを使用します[グループをクラスターに整理する](emla-deploy-design-cluster.md#emla-deploy-design-organize-cluster)。次の点に注意してください。
+ この例では、クラスター CL-A とクラスター CL-B は同じ 2 つのネットワークを共有します。デプロイでは、クラスターがネットワークを共有しない場合があります。
+ この例では、両方のクラスターの論理インターフェイスに同じ名前を割り当てます。ただし、異なる名前を割り当てることもできます。
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/medialive/latest/ug/emla-design-mappings.html)
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/medialive/latest/ug/emla-design-mappings.html)
この情報は次のように使用します。
+ ネットワーク名: [各ネットワークを作成する](emla-setup-cl-networks.md)ときにこの名前を割り当てます。
+ クラスター名: [各クラスターを作成する](emla-setup-cluster.md)ときにこの名前を割り当てます。
+ 論理インターフェイス名: この名前を割り当てて、[各クラスターの作成](emla-setup-cluster.md)時に**インターフェイスマッピングフィールドに入力します**。
+ 物理インターフェイス: ノードを作成するときに、この情報を入力してノード**インターフェイスマッピング**フィールドに入力します。 [ノードを作成します](emla-setup-cl-nodes-create.md)
# MediaLive Anywhere の IAM でのセットアップ
でいくつかのセットアップを実行する必要があります AWS Identity and Access Management。MediaLive コンソールでネットワーク、クラスター、ノードを作成する前に、この設定を実行する必要があります。
IAM ユーザーまたは管理ユーザーとして既に設定されているユーザーは、このセクションのタスクを実行します。
**Topics**
+ [インスタンスロールの作成](emla-deploy-instance-role.md)
+ [ユーザーのセットアップ](emla-deploy-users.md)
+ [MediaLive の信頼されたエンティティの変更](emla-deploy-modify-ml-trusted-entity.md)
# インスタンスロールの作成
MediaLive Anywhere を使用するには、MediaLive が実行されているオンプレミスノードハードウェアで AWS Systems Manager がアクションを実行できるようにする、信頼されたエンティティ設定を作成する必要があります。ロールを作成し、特定のコンテンツを含む一部のポリシーをアタッチし、そのロールの信頼されたエンティティとして (Systems Manager) を指定 AWS Systems Manager する必要があります。
この図では、ロールはピンク色のボックスにあり、各ポリシーは黄色のボックスにあり、信頼された各エンティティは青色のボックスにあります。
![\[Instance Role connected to three policies and a trust relationship with AWS Systems Manager.\]](http://docs.aws.amazon.com/ja_jp/medialive/latest/ug/images/instance-role-access.png)
このロールが作成されると、MediaLive Anywhere をデプロイしている MediaLive ユーザーは、作成した各クラスターにこのロールをアタッチします。すべてのクラスターに同じロールをアタッチします。このロールとその信頼されたエンティティは、次のステートメントを作成します。
「このクラスター内のノードの場合、Systems Manager は、ロールにアタッチされているポリシーで指定されたリソースに対してオペレーションを実行するために、このロールを引き受けることができます。」
**Topics**
+ [ポリシーの作成](#emla-deploy-instance-role-policy)
+ [ロールを作成する](#emla-deploy-instance-role-create-role)
## ポリシーの作成
MediaLiveAnywhereAccess ポリシーを作成する必要があります。これは図の一番上の黄色のボックスです。（他の 2 つのポリシーは IAM に既に存在する管理ポリシーであるため、作成する必要はありません。）
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。
1. 左側のナビゲーションペインで、**[ポリシー]** を選択します。次に、[**Create policy（ポリシーの作成）**] を選択します。表示されるページで、JSON ****ビュー (**ビジュアル**ビューではなく) を選択します。
1. すべてのサンプルを消去し、次のテキストをコピーします。テキストを編集して、*111122223333* の両方のインスタンスを AWS アカウント番号に変更します。改訂されたテキストを**ポリシーエディタ **に貼り付けます。
最初のステートメントでは、リソース行は、任意の AWS リージョン (アカウントの前の **\$1** ワイルドカードで指定) の指定されたアカウントのクラスターを識別します。
2 番目のステートメントでは、リソースラインは任意の AWS リージョンの指定されたアカウントの **MediaLiveAccessRole** を識別します (ワイルドカードは不要であることに注意してください）。
1. [**次へ**] を選択します。ポリシーに名前を付けます。この名前は、**MediaLiveAnywhereAccess** とすることをお勧めします。
1. [**Create policy**] (ポリシーの作成) を選択します。
## ロールを作成する
インスタンスロールを作成する必要があります。これは図のピンク色のボックスです。
1. IAM コンソールの左側のナビゲーション ペインで、**ロール**を選択し、**ロールを作成します**。**ロールの作成**ウィザードが表示されます。このウィザードでは、信頼できるエンティティを設定し、アクセス許可を追加する (ポリシーを追加) 手順を説明します。
1. **[信頼されたエンティティを選択]** ページで、**[カスタム信頼ポリシー]** カードを選択します。**カスタム信頼ポリシー**セクションが表示され、サンプルステートメントが表示されます。
1. すべてのサンプルを消去し、次のテキストをコピーして、**カスタム信頼ポリシー**セクションにテキストを貼り付けます。[**次へ**] を選択します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": ["medialive.amazonaws.com", "ssm.amazonaws.com"]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. アクセス**許可の追加**ページで、次のポリシーを検索し、各ポリシーのチェックボックスを選択します。
+ 作成したポリシー。レコメンデーションに従った場合、このポリシーの名前は `MediaLiveAnywhereAccess`)
+ `AmazonEC2ContainerServiceforEC2Role` ポリシー
+ `AmazonSSMManagedInstanceCore` ポリシー
コンソールでは、**アクセス許可ポリシー**のタイトルの横にあるカウンターに **3/xxx** が表示され、3 つのポリシーが選択されていることを示します。
1. [**次へ**] を選択します。
1. レビューページで、役割の名前を入力します。この名前は、**MediaLiveAnywhereInstanceRole** とすることをお勧めします。
1. [**ロールの作成**] を選択してください。
1. ロールの**Summary**ページで、**Role ARN**の値をメモしてください。以下のように表示されます。
`arn:aws:iam::111122223333:role/MediaLiveAnywhereInstanceRole`
この例では、 `111122223333`は AWS アカウント番号です。
# ユーザーのセットアップ
MediaLive Anywhere クラスターを設定できるように、および/またはオンプレミスノードハードウェアでチャネルを実行できるように、アクセス許可を持つ IAM ユーザーを設定する必要があります。
IAM ユーザーまたは管理ユーザーとして既に設定されているユーザーは、このセクションのタスクを実行します。
**Topics**
+ [ユーザーを作成してアクセス許可を割り当てる](emla-deploy-users-permissions.md)
+ [特別な FAS ポリシーを作成する](emla-deploy-users-ecs-permissions.md)
# ユーザーを作成してアクセス許可を割り当てる
オンプレミスハードウェアでチャネルを実行するユーザーを設定していない場合は、今すぐ設定する必要があります。組織が MediaLive の現在のユーザーであり、現在 MediaLive Anywhere をデプロイしている場合は、既存のユーザーのアクセス許可を変更する必要があります。「[AWS Elemental MediaLive の Identity and Access Management](security-iam.md)」および「[ユーザーにIAM権限を設定する](setting-up-for-production.md)」を参照してください。
どちらのシナリオでも、2 つのガイドラインがあります。
+ ユーザーを作成または変更するときは、MediaLive Anywhere を使用するように特別に設計されたロールとポリシーを作成することをお勧めします。
+ MediaLive Anywhere を操作するために必要なアクセス許可を含める必要があります。「[MediaLive Anywhere の要件](requirements-for-emla.md)」を参照してください。
# 特別な FAS ポリシーを作成する
MediaLive Anywhere ユーザーにアクセス許可を割り当てたら、次の 2 つの追加ポリシーを作成する必要があります。
+ クラスターを作成できるユーザーのロールにアタッチする必要があるクラスターの作成ポリシー。このポリシーにより、MediaLive は Amazon Elastic Container Service に Amazon ECS クラスターを作成するためのリクエストを送信できます。
+ ノードを作成できるユーザーのロールにアタッチする必要があるノード登録ポリシー。このポリシーにより、MediaLive は Amazon Elastic Container Service に Amazon ECS サービスを作成するためのリクエストを送信できます。
これらのポリシーの両方により、MediaLive は IAM 転送アクセスセッション (FAS) を使用してリクエストを行うことができます。
## クラスター作成ポリシーを作成する
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。
1. 左側のナビゲーションペインで、**[ポリシー]** を選択します。次に、[**Create policy（ポリシーの作成）**] を選択します。表示されるページで、**JSON **ビュー (**ビジュアル**ビューではなく) を選択します。
1. サンプルを消去し、この手順の最後にあるテキストをコピーして、**ポリシーエディタ**に貼り付けます。
1. [**次へ**] を選択します。ポリシーに名前を付けます。この名前は、**MediaLiveAnywhereCreateCluster** とすることをお勧めします。
1. [**Create policy**] (ポリシーの作成) を選択します。
## ノード登録ポリシーを作成する
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。
1. 左側のナビゲーションペインで、**[ポリシー]** を選択します。次に、[**Create policy（ポリシーの作成）**] を選択します。表示されるページで、**JSON **ビュー (**ビジュアル**ビューではなく) を選択します。
1. サンプルを消去し、この手順の最後にあるテキストをコピーして、**ポリシーエディタ**に貼り付けます。
1. [**次へ**] を選択します。ポリシーに名前を付けます。この名前は、**MediaLiveAnywhereRegisterScript** とすることをお勧めします。
1. [**Create policy**] (ポリシーの作成) を選択します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMCreateActivation",
"Effect": "Allow",
"Action": [
"ssm:AddTagsToResource",
"ssm:CreateActivation"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/created_by": "MediaLiveAnywhere"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"ssm.amazonaws.com"
]
}
}
}
]
}
```
------
# MediaLive の信頼されたエンティティの変更
MediaLive 用に作成した信頼されたエンティティロールを変更する必要があります。[この信頼エンティティ を既に設定](setting-up-trusted-entity.md)しているはずです。
設定したロールを変更する必要があります。
+ [シンプルなオプション で を設定](setup-trusted-entity-simple.md)した場合、このロールには`MediaLiveAccessRole`という名前が付けられます。
+ [複合オプション で を設定する](setup-trusted-entity-complex.md)場合、このロールには目的を説明する名前があります。[ロールを作成します](complex-scenario-create-trusted-entity-role-step3.md)では、`MedialiveAccessRoleForSports`などの名前を提案しました。
複数のロールがある場合があります。オンプレミスノードハードウェアで実行される少なくとも 1 つのチャネルで使用されるすべてのロールを特定します。
アクション`sts:TagSession`を含めるようにロールを変更する必要があります。
指定した各ロールを変更するには、次の手順に従います。
1. IAMコンソールの左側のナビゲーションペインで、**[Roles]**を選択し、変更するロールを見つけます。
1. 概要ページで、**信頼関係**ページを選択しました。現在の信頼ステートメントが表示されます。**[Edit trust policy]** (信頼ポリシーを編集) を選択します。
1. 既存の信頼ポリシーは、おそらく次のようになります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "medialive.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. `Action` 行を次の 2 つのアクションの配列に変更します。
```
"Action": ["sts:AssumeRole", "sts:TagSession"]
```
1. [**ポリシーの更新**] を選択してください。
# クラスターの作成
AWS Elemental MediaLive Anywhere クラスターを[設計](#emla-setup-cluster)したときに特定したネットワーク、クラスター、ノード、SDI ソースを作成する必要があります。
まずネットワークを作成し、次にクラスターを作成し、次にノードを作成します。作業の順序に関する他のルールはありません。例えば、すべてのネットワークを作成し、すべてのクラスターを作成し、すべてのノードを作成できます。または、1 つのクラスターのネットワークを作成し、クラスターを作成し、そのクラスターのノードを作成します。
**Topics**
+ [ネットワークを作成する](emla-setup-cl-networks.md)
+ [クラスターを作成する](emla-setup-cl-create.md)
+ [ノードを作成します](emla-setup-cl-nodes-create.md)
+ [SDI ソースを作成する](emla-setup-cl-sdi.md)
+ [このセットアップの結果](emla-setup-cl-result.md)
# ネットワークを作成する
[クラスター を設計](emla-deploy-design-cluster.md)したときに識別したネットワークを作成します。ネットワークを作成すると、[識別したリソース](emla-deploy-identify-network-requirements.md)が AWS Elemental MediaLive Anywhere に統合されます。他の MediaLive Anywhere リソースを作成する前に、ネットワークを作成する必要があります。
1. [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/) で MediaLive コンソールを開きます。
1. ナビゲーションバーで MediaLive Anywhere を選択し、**Networks **を選択します。**ネットワーク**ページで、**ネットワークの作成 **を選択します。
1. フィールドには、ネットワークエンジニアが[ネットワークリソースの特定](emla-deploy-identify-network-requirements.md)で提供した情報を入力します。
1. **[作成]** を選択します。MediaLive Anywhere はネットワークを作成し、ネットワークのリストに追加します。
# クラスターを作成する
ネットワークを作成したら、クラスターを作成します。
1. ナビゲーションバーで MediaLive Anywhere を選択し、**クラスター **を選択します。[**Clusters**] ページで、[**Create Cluster**] を選択します。
1. フィールドに入力します。
+ **名前 **: クラスター内のノードのタイプをヒントにする名前を割り当てることをお勧めします。
+ **インスタンスロール ARN **: MediaLive のインスタンスロールを選択する必要があります。組織の AWS 管理ユーザーから ARN を取得します。このインスタンスの役割については、「[インスタンスロールの作成](emla-deploy-instance-role.md)」を参照してください。
+ **インターフェイスマッピング **:[ノードインターフェイスのマッピングの設計](emla-design-mappings.md)を参照してください。
+ **デフォルトルート **: ネットワークエンジニアが[ネットワークリソースの特定](emla-deploy-identify-network-requirements.md)で識別したデフォルトである論理インターフェイス名 (**インターフェイスマッピング **から) を選択します。
1. [Create] (作成) を選択します。MediaLive Anywhere はクラスターを作成し、クラスターのリストに追加します。
# ノードを作成します
1 つのクラスターのすべてのノードを作成します。クラスターを作成した後、およびクラスターとネットワークの設定を確定した後に作成します。
**重要**
ネットワークに関連付けられたクラスターにノードを追加した後、ネットワークを変更することはできません。
ノードを作成するには、ノード登録スクリプトを作成し、各ノードハードウェアユニットでスクリプトを実行します。次に、各ハードウェアユニットでスクリプトを実行します。
## ノードハードウェアを準備する
MediaLive Anywhere ノードのハードウェアを既に取得しているはずです。
各ノードに RHEL 9.5 オペレーティングシステムをインストールします。RHEL 9.5 のみがサポートされているバージョンです。
## ノード登録スクリプトを作成する
1. ナビゲーションバーで MediaLive Anywhere を選択し、**クラスター **を選択します。クラスタのリストで、ノードを追加するクラスタの名前を選択します。**[詳細]** ページが表示されます。
1. 下にスクロールして、**Nodes** タブを選択します。**ノードの作成 **を選択します。
1. **ノードの作成**ページで、次のフィールドに入力します。スクリプトは、ここに入力した値を使用します。
+ **名前**： このノードに恒久的に割り当てる名前。
+ **ノードロール **: **アクティブ**または**バックアップ **を選択します。[クラスター を設計](emla-deploy-design-cluster.md#emla-deploy-design-organize-cluster)するときに、これらのロールを特定しているはずです。
+ **ノードインターフェイスマッピング **:[ノードインターフェイスのマッピングの設計](emla-design-mappings.md)で識別したマッピングを作成します。
1. **[作成]** を選択します。
1. コンソールのページの上部までスクロールします。ノードの追加リクエストが成功すると、バナーにメッセージと登録スクリプトの内容が表示されます。
1. **スクリプトのコピー**を選択して、コンソールを使用しているコンピュータのクリップボードにスクリプトをコピーします。次に、次のステップに進み、スクリプトを実行します。
## ノードをアクティブ化します
ノード登録スクリプトは、スクリプトの作成から 24 時間以内に実行する必要があります。各スクリプトは 1 つのノードでのみ実行する必要があります。スクリプトには、ノードのクラスターで一意である必要があるノード名などのデータが含まれているためです。
1. ノードで SSH セッションを開始します。
1. プロンプトで、このノードのノード登録スクリプトを貼り付け、**Enter **を押します。スクリプトは以下のアクションを実行します。
+ ノード ID (ノードの作成時に指定した) をこのノードハードウェアにバインドします。
+ 次に、MediaLive Anywhere で使用するノードハードウェアをアクティブ化します。このアクティベーションには約1分かかります。
## ノードの状態を確認する
1. MediaLiveコンソールのナビゲーションバーで、**ノード**を選択します。（**クラスター **は選択しないでください）。
1. **Nodes** リストで、ノードの状態が **の登録**であることを確認します。しばらくすると、状態は**アクティブ **に変わります。
# SDI ソースを作成する
クラスター内のノードの一部に SDI カードとポートが含まれている場合は、SDI ソースと SDI マッピングを作成する必要があります。
+ SDI ソース: MediaLive Anywhere は、対応するカードを持つノードがあることを前提として、シングルリンクおよびクアッドリンクの SDI インターフェイスをサポートしています。クワッドリンクソースの場合、MediaLive Anywhere はクワドラントモードまたはインターリーブモードをサポートしています。
+ SDI マッピング: SDI カードのポートごとに SDI マッピングを作成します。マッピングを使用すると、MediaLive Anywhere を設定して、SDI ソースをそのソースの接続ポイントである物理 SDI カードとポートに接続できます。
## SDI 入力の計画
1. SDI ソースを特定し、それぞれに AWS アカウントで一意の名前を付けます。など、ソースを記述する名前を割り当てることをお勧めします、例:**curling-cameraA**。
1. 各ソースのタイプ (シングルリンクまたはクワッドリンク) と、任意のクワッドリンクソースのモード (インターリーブまたはクワッド) を特定します。
1. SDI ソースをノードに接続する方法を計画します。具体的には、クワッドリンクであるソースを特定し、そのソースに 4 つの連続ポートを割り当てます。
1. 各 SDI ソースのカード番号とポート (またはポート) を特定します。ノードハードウェアで物理カードとポートを識別する方法については、ノードハードウェアのドキュメントを参照してください。
最終的には、各 SDI ソースのマッピングになります。各マッピングは、ソース名、カード番号、ポート番号で構成されます。
## SDI ソースを作成する
MediaLive Anywhere で使用する予定の各 SDI ソースを設定する必要があります。MediaLive で SDI 入力を作成するときに、このソースを参照します。
1. ナビゲーションバーで MediaLive Anywhere を選択し、**SDI ソース **を選択します。[**SDI sources**] (SDI ソース) タブで [**Connect SDI source**] (SDI ソースを接続する) を選択します。
1. フィールドに入力して、名前、インターフェイス、モード (クアッドリンクのみ) を指定します。
1. **[作成]** を選択します。
## SDI マッピングを作成します。
SDI ケーブルが接続されている各ノードに SDI マッピングを作成します。このタスクは、既存のノードを編集して実行します。
1. MediaLive ナビゲーションバーで、**ノード**を選択します。
1. ノードを選択してから、**[Edit]** (編集) を選択します。**編集**ページ。**SDI ソースマッピング**フィールドで、**マッピングの追加 **を選択します。
1. 3 つのフィールドに入力して、ソースを SDI カードとポート (チャネル番号) にマッピングします。
# このセットアップの結果
これで、MediaLive Anywhere デプロイのハードウェアとネットワークのセットアップが実行されました。これで、ビデオエンジニアが各クラスターにチャネルプレイスメントグループを作成し、チャネルプレイスメントグループに追加するチャネルを作成する準備が整いました。