セルフホステッド統合ランタイムを作成して構成する

適用対象: Azure Data Factory Azure Synapse Analytics

統合ランタイム (IR) は、異なるネットワーク環境間でデータ統合機能を提供するために Azure Data Factory と Synapse パイプラインによって使用されるコンピューティング インフラストラクチャです。 IR の詳細については、ランタイム統合の概要に関するページを参照してください。

セルフホステッド統合ランタイムにより、クラウド データ ストアとプライベート ネットワーク内のデータ ストアの間でコピー アクティビティを実行できます。 また、オンプレミス ネットワークまたは Azure Virtual Network 内のコンピューティング リソースに対して変換アクティビティをディスパッチすることができます。 セルフホステッド統合ランタイムは、オンプレミス コンピューター、またはプライベート ネットワーク内の仮想マシンにインストールする必要があります。

この記事では、セルフホステッド IR を作成して構成する方法について説明します。

セルフホステッド IR の使用に関する注意点

• 1 つのセルフホステッド統合ランタイムを複数のオンプレミス データ ソースで使用できます。 同じ Microsoft Entra テナント内の別のデータ ファクトリと共有することもできます。 詳細については、セルフホステッド統合ランタイムの共有に関するセクションを参照してください。
• 単一コンピューター上にインストールできるセルフホステッド統合ランタイムのインスタンスは 1 つのみとなります。 オンプレミス データ ソースにアクセスする必要があるデータ ファクトリが 2 つある場合、セルフホステッド IR 共有機能を使用してセルフホステッド IR を共有するか、2 台のオンプレミス コンピューター (データ ファクトリまたは Synapse ワークスペースにそれぞれ 1 台) 上にセルフホステッド IR をインストールします。 Synapse ワークスペースでは、Integration Runtime の共有はサポートされていません。
• セルフホステッド統合ランタイムは、データ ソースと同じコンピューター上に存在する必要はありません。 しかし、セルフホステッド統合ランタイムをデータ ソースの近くに配置することにより、セルフホステッド統合ランタイムからデータ ソースへの接続時間が短縮されます。 セルフホステッド統合ランタイムは、オンプレミス データ ソースをホストするコンピューターとは異なるコンピューターにインストールすることをお勧めします。 セルフホステッド統合ランタイムとデータ ソースが別のコンピューター上にある場合、セルフホステッド統合ランタイムではリソースのデータ ソースとの競合は発生しません。
• 同じオンプレミス データ ソースに接続する異なるコンピューター上で、複数のセルフホステッド統合ランタイムを使用することができます。 たとえば、2 つのデータ ファクトリを提供する 2 つのセルフホステッド統合ランタイムがある場合、どちらのデータ ファクトリにも同じオンプレミス データ ソースを登録できます。
• セルフホステッド統合ランタイムを使用して、Azure Virtual Network 内のデータ統合をサポートします。
• Azure ExpressRoute を使用する場合でも、ファイアウォールの背後にあるオンプレミス データ ソースとしてデータ ソースを扱います。 セルフホステッド統合ランタイムを使用して、サービスをデータ ソースに接続します。
• データ ストアがクラウド内の Azure IaaS (サービスとしてのインフラストラクチャ) 仮想マシン上にある場合でも、セルフホステッド統合ランタイムを使用します。
• FIPS 準拠の暗号化が有効になっている Windows Server 上にインストールされているセルフホステッド統合ランタイムでは、タスクが失敗する可能性があります。 この問題を回避するには、資格情報/シークレット値を Azure Key Vault に保存するか、またはサーバーで FIPS 準拠の暗号化を無効にする 2 つのオプションがあります。 FIPS 準拠の暗号化を無効にするには、レジストリ サブキー HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled の値を 1 (有効) から 0 (無効) に変更します。 セルフホステッド統合ランタイムを SSIS 統合ランタイムのプロキシとして使用する場合、FIPS 準拠の暗号化を有効にすることができ、オンプレミスからステージング領域として Azure Blob Storage にデータを移動するときに使用されます。
• 完全なライセンスの詳細は、セルフホステッド統合ランタイム セットアップの最初のページで提供されます。

コマンド フローとデータ フロー

オンプレミスとクラウドの間でデータを移動する場合、アクティビティではセルフホステッド統合ランタイムを使用して、オンプレミス データ ソースとクラウドの間でデータを転送します。

セルフホステッド IR でコピーするデータ フロー手順の概要を以下に示します。

1. まず、データ開発者は、Azure portal または PowerShell コマンドレットを使用して、Azure データ ファクトリまたは Synapse ワークスペース内にセルフホステッド統合ランタイムを作成します。 次にデータ開発者は、サービスがデータ ストアに接続するために使用する必要があるセルフホステッド統合ランタイムのインスタンスを指定して、オンプレミスのデータ ストア用のリンクされたサービスを作成します。

2. セルフホステッド統合ランタイム ノードでは、Windows DPAPI (Data Protection Application Programming Interface) を使用して資格情報を暗号化し、その資格情報をローカルに保存します。 高可用性を目的として複数ノードが設定されている場合、資格情報はさらに他のノード間で同期されます。 各ノードでは、DPAPI を使用して資格情報を暗号化し、それらをローカルに格納します。 資格情報の同期は、データ開発者に透過的であり、セルフホステッド IR によって処理されます。

3. Azure Data Factory と Synapse パイプラインによってセルフホステッド統合ランタイムとの通信が行われ、ジョブのスケジュール設定と管理が実行されます。 通信は、Azure Relay 共有接続を使用する制御チャネルを介して行われます。 アクティビティ ジョブを実行する必要がある場合、サービスによって、要求と資格情報がキューに置かれます。 これは、セルフホステッド統合ランタイムに資格情報がまだ格納されていない場合に備えて行われます。 セルフホステッド統合ランタイムでは、そのキューをポーリングした後、ジョブを開始します。

4. セルフホステッド統合ランタイムによって、オンプレミス ストアとクラウドとの間でデータがコピーされます。 コピーの方向は、データ パイプライン内でのコピー アクティビティの構成方法によって異なります。 この手順では、セルフホステッド統合ランタイムは、セキュリティで保護された HTTPS チャネルを使用して、クラウド ベースのストレージ サービス (Azure Blob Storage など) と直接通信を行います。

前提条件

• サポートされている Windows のバージョンは次のとおりです。
  • Windows 10
  • Windows 11
  • Windows Server 2016
  • Windows Server 2019
  • Windows Server 2022

セルフホステッド統合ランタイムのドメイン コントローラーへのインストールはサポートされていません。

• セルフホステッド統合ランタイムには、.NET Framework 4.7.2 以降を含む 64 ビット オペレーティング システムが必要です。 詳細については、「 .NET Framework システム要件 」をご覧ください。
• セルフホステッド統合ランタイム コンピューターに推奨される最小構成は、4 コアの 2 GHz プロセッサ、8 GB の RAM、および 80 GB の使用可能なハード ドライブ領域です。 システム要件の詳細については、ダウンロードのページを参照してください。
• ホスト コンピューターが休止状態の場合、セルフホステッド統合ランタイムはデータ要求に応答しません。 セルフホステッド統合ランタイムをインストールする前に、コンピューターに適切な電源プランを構成します。 コンピューターが休止状態に入るよう構成されている場合、セルフホステッド統合ランタイムのインストーラーによりメッセージが出力されます。
• セルフホステッド統合ランタイムを正常にインストールして構成するには、コンピューターの管理者である必要があります。
• コピー アクティビティは特定の頻度で実行されます。 コンピューター上のプロセッサおよび RAM の使用量は、ピーク時とアイドル時のある同じパターンに従います。 また、リソース使用量は、移動されるデータの量に大きく依存します。 複数のコピー ジョブが進行中のときには、ピーク時にリソース使用率が上昇します。
• Parquet、ORC、または Avro 形式のデータの抽出中にタスクが失敗することがあります。 Parquet の詳細については、「Azure Data Factory での Parquet 形式」を参照してください。 ファイルの作成は、セルフホステッド統合コンピューターで実行されます。 予想どおりに動作するには、ファイルの作成に次の前提条件が必要です。
  • Microsoft OpenJDK 11 や Eclipse Temurin 11 などの JRE プロバイダーからの Java Runtime (JRE) バージョン 11。 JAVA_HOME システム環境変数に (JRE フォルダーだけでなく) JDK フォルダーが設定されていることを確認します。システムの PATH 環境変数に bin フォルダーを追加することが必要な場合もあります。

  Note

  Parquet 形式に関するドキュメントで説明されているとおり、メモリ エラーが発生した場合は、Java の設定を調整する必要がある場合があります。

セルフホステッド統合ランタイムをセットアップする

セルフホステッド統合ランタイムを作成およびセットアップするには、次の手順に従います。

Azure PowerShell を使用してセルフホステッド IR を作成する

1. このタスクには Azure PowerShell を使用できます。 たとえば次のようになります。

   Set-AzDataFactoryV2IntegrationRuntime -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName -Type SelfHosted -Description "selfhosted IR description"
   

2. セルフホステッド統合ランタイムをローカル コンピューターにダウンロードしてインストールします。

3. 認証キーを取得し、そのキーを使用してセルフホステッド統合ランタイムを登録します。 PowerShell の例を次に示します。

   
   Get-AzDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName  
   
   

Azure Government で PowerShell コマンドを実行します。「PowerShell を使用して Azure Government に接続する」を参照してください。

UI を使用してセルフホステッド IR を作成する

Azure Data Factory または Azure Synapse の UI を使用してセルフホステッド IR を作成するには、次の手順に従います。

UI を使用してセルフホステッド IR を構成する

1. IR の名前を入力し、 [作成] を選択します。

2. [Integration runtime setup](統合ランタイムのセットアップ) ページで、 [Option 1](オプション 1) の下にあるリンクを選択して、コンピューターで高速セットアップを開きます。 または、オプション 2 の手順に従って、手動でセットアップします。 以降の手順は、手動セットアップに基づいています。

   

   1. 認証キーをコピーして貼り付けます。 [統合ランタイムのダウンロードとインストール] を選択します。

   2. セルフホステッド統合ランタイムをローカルの Windows マシンにダウンロードします。 インストーラーを実行します。

   3. [統合ランタイム (セルフホステッド) の登録] ページで、前に保存したキーを貼り付け、 [登録] を選択します。

      

   4. [新しい統合ランタイム (セルフホステッド) ノード] ページで [完了] を選択します。

3. セルフホステッド統合ランタイムが正常に登録されると、次のウィンドウが表示されます。

   

Azure Resource Manager テンプレートを使用して Azure VM にセルフホステッド IR をセットアップする

セルフホステッド IR の作成テンプレートを使用して、Azure 仮想マシンでのセルフホステッド IR のセットアップを自動化できます。 このテンプレートを使用すると、Azure 仮想ネットワーク内で完全に機能するセルフホステッド IR を簡単に作成できます。 ノード数を 2 以上に設定している限り、IR には高可用性とスケーラビリティの機能があります。

ローカル PowerShell を使用して既存のセルフホステッド IR をセットアップする

コマンド ラインを使用して、既存のセルフホステッド IR を設定または管理できます。 この使用方法は、セルフホステッド IR ノードのインストールと登録を自動化するのに特に役立ちます。

Dmgcmd.exe は、セルフホステッド インストーラーに含まれています。 これは、通常は、C:\Program Files\Microsoft Integration Runtime\5.0\Shared\ フォルダーに置かれます。 このアプリケーションはさまざまなパラメーターをサポートしており、自動化のためにバッチ スクリプトを使用してコマンド ラインから呼び出すことができます。

次のようにアプリケーションを使用します。

dmgcmd ACTION args...

アプリケーションのアクションと引数の詳細を次に示します。

ACTION	args	説明
-rn, -RegisterNewNode	"<AuthenticationKey>" ["<NodeName>"]	指定された認証キーおよびノード名を使用して、セルフホステッド統合ランタイム ノードを登録します。
-era, -EnableRemoteAccess	"<port>" ["<thumbprint>"]	現在のノードでリモート アクセスを有効にして、高可用性クラスターをセットアップします。 または、セルフホステッド IR に対する資格情報の設定を、Azure Data Factory または Azure Synapse ワークスペースを介さずに直接実行できるようにします。 後者を実行するには、同じネットワーク内のリモート コンピューターから New-AzDataFactoryV2LinkedServiceEncryptedCredential コマンドレットを使用します。
-erac, -EnableRemoteAccessInContainer	"<port>" ["<thumbprint>"]	ノードがコンテナーで実行されているときに、現在のノードへのリモート アクセスを有効にします。
-dra, -DisableRemoteAccess		現在のノードへのリモート アクセスを無効にします。 マルチノード設定にはリモート アクセスが必要です。 New-AzDataFactoryV2LinkedServiceEncryptedCredential PowerShell コマンドレットは、リモート アクセスが無効な場合でも機能します。 この動作は、コマンドレットがセルフホステッド IR ノードと同じコンピューター上で実行されている場合に当てはまります。
-k, -Key	"<AuthenticationKey>"	以前の認証キーを上書きまたは更新します。 この操作には注意してください。 キーが新しい統合ランタイムのものである場合、これにより以前のセルフホステッド IR ノードがオフラインになる可能性があります。
-gbf, -GenerateBackupFile	"<filePath>" "<password>"	現在のノードのバックアップ ファイルを生成します。 バックアップ ファイルには、ノード キーとデータ ストアの資格情報が含まれています。
-ibf, -ImportBackupFile	"<filePath>" "<password>"	バックアップ ファイルからノードを復元します。
-r, -Restart		セルフホステッド統合ランタイムのホスト サービスを再開します。
-s, -Start		セルフホステッド統合ランタイムのホスト サービスを開始します。
-t, -Stop		セルフホステッド統合ランタイムのホスト サービスを停止します。
-sus, -StartUpgradeService		セルフホステッド統合ランタイムのアップグレード サービスを開始します。
-tus, -StopUpgradeService		セルフホステッド統合ランタイムのアップグレード サービスを停止します。
-tonau, -TurnOnAutoUpdate		セルフホステッド統合ランタイムの自動更新を有効にします。 このコマンドは、Azure Data Factory V1 のみを対象としています。
-toffau, -TurnOffAutoUpdate		セルフホステッド統合ランタイムの自動更新を無効にします。 このコマンドは、Azure Data Factory V1 のみを対象としています。
-ssa, -SwitchServiceAccount	"<domain\user>" ["<password>"]	DIAHostService を新しいアカウントとして実行するように設定します。 システム アカウントおよび仮想アカウントの場合は空のパスワード "" を使用します
-elma, -EnableLocalMachineAccess		現在のセルフホステッド IR ノードで、ローカル マシン アクセス (ローカルホスト、プライベート IP) を有効にします。 セルフホステッド IR 高可用性シナリオでは、セルフホステッド IR ノードごとにアクションを呼び出す必要があります。
-dlma, -DisableLocalMachineAccess		現在のセルフホステッド IR ノード上のローカル マシンア クセス (ローカルホスト、プライベートIP) を無効にします。 セルフホステッド IR 高可用性シナリオでは、セルフホステッド IR ノードごとにアクションを呼び出す必要があります。
-DisableLocalFolderPathValidation		セキュリティ検証を無効にして、ローカル コンピューターのファイル システムへのアクセスを有効にします。
-EnableLocalFolderPathValidation		セキュリティ検証を有効にして、ローカル コンピューターのファイル システムへのアクセスを無効にします。
-eesp, -EnableExecuteSsisPackage		セルフホステッド IR ノードで SSIS パッケージの実行を有効にします。
-desp, -DisableExecuteSsisPackage		セルフホステッド IR ノードで SSIS パッケージの実行を無効にします。
-gesp, -GetExecuteSsisPackage		セルフホステッド IR ノードで ExecuteSsisPackage オプションが有効になっている場合は、値を取得します。 戻り値が true の場合、ExecuteSSISPackage が有効になります。戻り値が false または null の場合、ExecuteSSISPackage は無効になります。

Microsoft ダウンロード センターからセルフホステッド IR をインストールして登録する

1. Microsoft Integration Runtime のダウンロード ページに移動します。

2. [ダウンロード] を選択し、64 ビット バージョンを選んでから [次へ] を選択します。 32ビット バージョンはサポートされていません。

3. MSI ファイルを直接実行するか、ハード ドライブに保存してから実行します。

4. [ようこそ] ウィンドウで言語を選び、 [次へ] を選択します。

5. マイクロソフト ソフトウェア ライセンス条項に同意して、 [次へ] を選択します。

6. セルフホステッド統合ランタイムをインストールするフォルダーを選んで、 [次へ] を選択します。

7. [インストールの準備完了] ページで [インストール] をクリックします。

8. [完了] を選択してインストールを完了します。

9. PowerShell を使用して認証キーを取得します。 認証キーを取得するための PowerShell の例を以下に示します。

   Get-AzDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName
   

10. ご利用のコンピューターで実行している Microsoft Integration Runtime 構成マネージャーの [統合ランタイム (セルフホスト) の登録] ウィンドウで、次の手順を行います。

    1. 認証キーをテキスト領域に貼り付けます。

    2. 必要に応じて、 [認証キーの表示] を選択してキー テキストを表示します。

    3. [登録] を選択します。

セルフホステッド統合ランタイムのサービス アカウント

セルフホステッド統合ランタイムの既定のログオン サービス アカウントは、NT SERVICE\DIAHostService です。 これは、[サービス] -> [Integration Runtime サービス] -> [プロパティ] -> [ログオン]で確認できます。

アカウントにサービスとしてのログオンの権限があることを確認します。 そうでないと、セルフホステッド統合ランタイムを正常に開始できません。 アクセス許可は、[ローカル セキュリティ ポリシー] -> [セキュリティの設定] -> [ローカル ポリシー] -> [ユーザー権利の割り当て] -> [サービスとしてログオン] で確認できます

通知領域のアイコンと通知

通知領域のアイコンまたはメッセージの上にカーソルを移動すると、セルフホステッド統合ランタイムの状態の詳細が表示されます。

高可用性とスケーラビリティ

セルフホステッド統合ランタイムを複数のオンプレミス マシンまたは Azure の仮想マシンに関連付けることができます。 これらのコンピューターは、ノードと呼ばれます。 セルフホステッド統合ランタイムには最大で 4 つのノードを関連付けることができます。 論理ゲートウェイ用にゲートウェイがインストールされているオンプレミス コンピューターに複数のノードを配置すると、次のような利点があります。

• セルフホステッド統合ランタイムの可用性の向上によって、ビッグ データ ソリューションまたはクラウド データ統合における単一障害点がなくなります。 この可用性により、最大 4 つのノードを使用する場合に継続性が確保されます。
• オンプレミスとクラウド データ ストアとの間のデータ移動は、パフォーマンスとスループットが向上しました。 詳しくはパフォーマンス比較を参照してください。

セルフホステッド統合ランタイム ソフトウェアをダウンロード センターからインストールして、複数のノードを関連付けることができます。 その後、チュートリアルの説明に従って、New-AzDataFactoryV2IntegrationRuntimeKey コマンドレットから取得した認証キーのいずれかを使用して、登録します。

スケールに関する考慮事項

スケール アウト

セルフホステッド IR で、プロセッサ使用率が高く、使用可能なメモリが低減している場合、複数のコンピューターで負荷をスケールアウトするために、新しいノードを追加します。 タイムアウトのため、またはセルフホステッド IR ノードがオフライン状態であるために、アクティビティが失敗した場合に、ノードをゲートウェイに追加すると役立ちます。 ノードを追加する場合は、次の手順を実行します。

1. Azure Data Factory ポータルから SHIR セットアップをダウンロードします。
2. クラスターに追加するノードでインストーラーを実行します。
3. インストール中に、既存の統合ランタイムに参加するオプションを選択し、既存の SHIR から認証キーを指定して、新しいノードを既存の SHIR クラスターにリンクします。

スケールアップ

プロセッサと使用可能な RAM はあまり使用されていないが、同時実行ジョブの実行がノードの制限に達した場合は、1 つのノードが実行できる同時実行ジョブの数を増やしてスケールアップします。 また、セルフホステッド IR が過負荷になっているために、アクティビティがタイムアウトになる場合も、スケールアップが必要になることがあります。 次の画像に示すように、ノードの最大容量を増やすことができます。

TLS/SSL 証明書の要件

統合ランタイム ノード間の通信をセキュリティで保護するために、TLS/SSL 証明書 (詳細) を使用してイントラネットからのリモート アクセスを有効にする場合は、TLS/SSL 証明書を使用してイントラネットからのリモート アクセスを有効にすることに関するページの手順に従ってください。

資格情報の同期

資格情報またはシークレット値を Azure Key Vault に格納しない場合、資格情報またはシークレットの値は、セルフホステッド統合ランタイムが配置されているマシンに格納されます。 各ノードには、特定のバージョンの資格情報のコピーがあります。 すべてのノードを連携させるには、すべてのノードでバージョン番号が同じである必要があります。

プロキシ サーバーに関する考慮事項

企業ネットワーク環境でプロキシ サーバーを使用してインターネットにアクセスする場合は、適切なプロキシ設定を使用するようにセルフホステッド統合ランタイムを構成します。 プロキシは、初期登録フェーズ中に設定できます。

構成されると、セルフホステッド統合ランタイムはプロキシ サーバーを使用してクラウド サービスのソースおよびコピー先 (HTTP または HTTPS プロトコルを使用しているもの) に接続します。 初期セットアップ時に [変更] リンクを選択したのはこのためです。

3 つの構成オプションがあります。

• プロキシを使用しない:セルフホステッド統合ランタイムは、クラウド サービスに接続するときにプロキシを明示的には使用しません。
• システム プロキシを使用する:セルフホステッド統合ランタイムでは、diahost.exe.config と diawp.exe.config で構成されているプロキシ設定を使用します。これらのファイルでプロキシ構成が指定されていない場合、セルフホステッド統合ランタイムではプロキシを経由せず、直接クラウド サービスに接続します。
• カスタム プロキシを使用する:diahost.exe.config と diawp.exe.config の構成は使用せず、セルフホステッド統合ランタイムで使用するように HTTP プロキシ設定を構成します。 [アドレス] と [ポート] の値は必須です。 [ユーザー名] と [パスワード] の値は、プロキシの認証設定によっては省略できます。 すべての設定は Windows DPAPI を使用して、自己ホスト型統合ランタイム上で暗号化され、コンピューターにローカルに格納されます。

統合ランタイムのホスト サービスは、更新済みのプロキシ設定を保存した後に自動的に再起動されます。

セルフホステッド統合ランタイムが登録された後、プロキシ設定を表示または更新する必要がある場合は、Microsoft Integration Runtime 構成マネージャーを使用します。

1. Microsoft Integration Runtime 構成マネージャーを開きます。
2. [設定] タブを選択します。
3. [HTTP プロキシ] の [変更] リンクを選択して、 [HTTP プロキシを設定する] ダイアログ ボックスを開きます。
4. [次へ] を選択します。 その後、プロキシ設定を保存して統合ランタイムのホスト サービスを再起動するためのアクセス許可を求める警告が表示されます。

構成マネージャー ツールを使用して、HTTP プロキシを表示して更新することができます。

プロキシ サーバーの設定を構成する

HTTP プロキシに対して [システム プロキシを使用する] オプションを選択すると、セルフホステッド統合ランタイムで、diahost.exe.config と diawp.exe.config のプロキシ設定が使用されます。これらのファイルでプロキシが指定されていない場合、セルフホステッド統合ランタイムではプロキシを経由せず、直接クラウド サービスに接続します。 diahost.exe.config ファイルを更新する手順を以下に示します。

1. エクスプローラーで、元のファイルのバックアップとして C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config のセーフ コピーを作成します。

2. 管理者として実行中のメモ帳を開きます。

3. メモ帳で、テキスト ファイル C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config を開きます。

4. 次のコードに示されている既定の system.net のタグを見つけます。

   <system.net>
       <defaultProxy useDefaultCredentials="true" />
   </system.net>
   

   その後、次の例で示すように、プロキシ サーバーの詳細を追加できます。

   <system.net>
       <defaultProxy enabled="true">
             <proxy bypassonlocal="true" proxyaddress="http://proxy.domain.org:8888/" />
       </defaultProxy>
   </system.net>
   

   プロキシ タグでは、scriptLocation のように必要な設定を指定するための追加のプロパティが許可されます。 構文については、「<proxy> 要素 (ネットワーク設定)」を参照してください。

   <proxy autoDetect="true|false|unspecified" bypassonlocal="true|false|unspecified" proxyaddress="uriString" scriptLocation="uriString" usesystemdefault="true|false|unspecified "/>
   

5. 元の場所に構成ファイルを保存します。 次に、セルフホステッド統合ランタイムのホスト サービスを再開して、変更を取得します。

   サービスを再開するには、コントロール パネルのサービス アプレットを使用します。 または、Integration Runtime 構成マネージャーから、 [サービスの停止] ボタンを選択し、 [サービスの開始] を選びます。

   サービスが開始されない場合は、不正確な XML タグ構文が編集済みのアプリケーション構成ファイルに追加されている可能性があります。

また、Microsoft Azure が会社の許可リストにあることを確認する必要もあります。 有効な Azure IP アドレスの一覧をダウンロードできます。 各クラウドの IP 範囲 (リージョン別とクラウド内のタグ付けされたサービス別に分けられています) を、MS ダウンロードから入手できるようになりました。

• パブリック: https://www.microsoft.com/download/details.aspx?id=56519
• US Gov: https://www.microsoft.com/download/details.aspx?id=57063
• ドイツ: https://www.microsoft.com/download/details.aspx?id=57064
• 中国: https://www.microsoft.com/download/details.aspx?id=57062

プライベート エンドポイントを使用するときにプロキシ サーバーの設定を構成する

会社のネットワークアーキテクチャにプライベート エンドポイントの使用が含まれており、セキュリティ上の理由から、会社のポリシーでセルフホステッド Integration Runtime をホストしている VM から Azure Data Factory サービス URL への直接接続が許可されていない場合は、完全な接続のために ADF サービス URL のバイパスを許可する必要があります。 diahost.exe.config ファイルを更新する手順を次に示します。 diawp.exe.config ファイルについても、これらの手順を繰り返す必要があります。

1. エクスプローラーで、元のファイルのバックアップとして C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config のセーフ コピーを作成します。

2. 管理者として実行中のメモ帳を開きます。

3. メモ帳で C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config を開きます。

4. 次に示す、既定の system.net タグを見つけます。

   <system.net>
       <defaultProxy useDefaultCredentials="true" />
   </system.net>
   

   その後、次の例で示すように、bypasslist の詳細を追加できます。

   <system.net>
     <defaultProxy>
         <bypasslist>
             <add address = "[adfresourcename].[adfresourcelocation].datafactory.azure.net" />
         </bypasslist>
         <proxy 
         usesystemdefault="True"
         proxyaddress="http://proxy.domain.org:8888/"
         bypassonlocal="True"
         />
     </defaultProxy>
   </system.net>
   

ファイアウォールとプロキシ サーバーに関する問題で発生する可能性がある症状

次のようなエラー メッセージが表示される場合は、ファイアウォールまたはプロキシ サーバーの構成が正しくない可能性があります。 このような構成では、セルフホステッド統合ランタイムで Data Factory または Synapse パイプラインに接続して自身を認証することができません。 ファイアウォールとプロキシ サーバーが確実に正しく構成されるようにするには、前のセクションを参照してください。

• セルフホステッド統合ランタイムを登録すると、次のエラー メッセージが表示されます。"この Integration Runtime ノードの登録に失敗しました。 認証キーが有効であり、Integration Runtime ホスト サービスがこのマシンで実行されていることをご確認ください。"

• Integration Runtime 構成マネージャーを開くと、 [切断] または [接続中] という状態が表示されます。 [イベント ビューアー]>[アプリケーションとサービス ログ]>[Microsoft Integration Runtime] の順に選択して Windows イベント ログを表示すると、次のようなエラー メッセージが表示されます。

  Unable to connect to the remote server
  A component of Integration Runtime has become unresponsive and restarts automatically. Component name: Integration Runtime (self-hosted).
  

イントラネットからのリモート アクセスを有効にする

PowerShell を使用して、セルフホステッド統合ランタイムがインストールされているのとは別のネットワーク接続されたコンピューターから資格情報を暗号化する場合、 [イントラネットからのリモート アクセス] オプションを有効にすることができます。 PowerShell を使用して、セルフホステッド統合ランタイムがインストールされているコンピューターで資格情報を暗号化する場合、 [イントラネットからのリモート アクセス] オプションを有効にすることはできません。

高可用性とスケーラビリティ用の別のノードを追加する前に、 [イントラネットからのリモート アクセス] を有効にしす。

既定では、セルフホステッド統合ランタイムのセットアップ バージョン 3.3 以降の実行時に、セルフホステッド統合ランタイムのインストーラーにより、セルフホステッド統合ランタイム コンピューター上の [イントラネットからのリモート アクセス] が無効化されます。

パートナーまたは他社のファイアウォールを使用する場合は、ポート 8060 またはユーザーが構成したポートを手動で開くことができます。 セルフホステッド統合ランタイムの設定中にファイアウォールの問題が発生した場合は、次のコマンドを使用して、ファイアウォールを構成せずにセルフホステッド統合ランタイムをインストールしてください。

msiexec /q /i IntegrationRuntime.msi NOFIREWALL=1

セルフホステッド統合ランタイム コンピューター上でポート 8060 を開かない場合は、資格情報の設定アプリケーション以外のメカニズムを使用して、データ ストア資格情報を構成します。 たとえば、New-AzDataFactoryV2LinkedServiceEncryptCredential PowerShell コマンドレットを使用できます。

ポートとファイアウォール

考慮すべきファイアウォールが 2 つあります。

• 組織の中央ルーターで実行されている "企業ファイアウォール"
• セルフホステッド統合ランタイムがインストールされているローカル コンピューターでデーモンとして実行されている "Windows ファイアウォール"

企業ファイアウォール レベルでは、次のドメインと送信ポートを構成する必要があります。

ドメイン名	送信ポート	説明
パブリック クラウド: *.servicebus.windows.net Azure Government: *.servicebus.usgovcloudapi.net 中国: *.servicebus.chinacloudapi.cn	443	セルフホステッド統合ランタイムがインタラクティブな作成を行うために必要です。 自己完結型のインタラクティブな編集が有効な場合は必須ではありません。
パブリック クラウド: {datafactory}.{region}.datafactory.azure.net または *.frontend.clouddatahub.net Azure Government: {datafactory}.{region}.datafactory.azure.us 中国: {datafactory}.{region}.datafactory.azure.cn	443	セルフホステッド統合ランタイムが Data Factory サービスに接続するために必要です。 パブリック クラウドに新しく作成された Data Factory の場合は、{datafactory}.{region}.datafactory.azure.net という形式のセルフホステッド統合ランタイム キーから完全修飾ドメイン名 (FQDN) を見つけてください。 古いデータ ファクトリおよびすべてのバージョンの Azure Synapse Analytics では、セルフホステッド統合キーに FQDN が表示されない場合、代わりに *.frontend.clouddatahub.net を使用してください。
download.microsoft.com	443	セルフホステッド統合ランタイムが更新プログラムをダウンロードするために必要です。 自動更新を無効にした場合は、このドメインの構成をスキップできます。
Key Vault の URL	443	Key Vault に資格情報を格納する場合は、Azure Key Vault に必要です。

Windows ファイアウォール レベル (コンピューター レベル) では、通常、これらの送信ポートが有効になっています。 有効になっていない場合は、セルフホステッド統合ランタイム コンピューターで、ドメインとポートを構成することができます。

お使いのソースやシンクに基づいて、追加のドメインと送信ポートを企業ファイアウォールまたは Windows ファイアウォールで許可しなければならない場合があります。

ドメイン名	送信ポート	説明
*.core.windows.net	443	ステージング コピー機能を使用する場合に、セルフホステッド統合ランタイムが Azure ストレージ アカウントに接続するために使用します。
*.database.windows.net	1433	Azure SQL Database または Azure Synapse Analytics との間でコピーするときにのみ必要です。その他の場合は省略可能です。 ポート 1433 を開かずに SQL Database または Azure Synapse Analytics にデータをコピーするには、ステージング コピー機能を使用します。
*.azuredatalakestore.net login.microsoftonline.com/<tenant>/oauth2/token	443	Azure Data Lake Store との間でコピーするときにのみ必要です。その他の場合は省略可能です。

Azure SQL Database や Azure Data Lake などの一部のクラウド データベースでは、そのファイアウォール構成でセルフホステッド統合ランタイム コンピューターの IP アドレスを許可しなければならない場合があります。

自己完結型のインタラクティブな編集 (プレビュー)

データ プレビューや接続テストなどのインタラクティブな編集 アクションを実行するには、セルフホステッド統合ランタイムで Azure Relay への接続が必要です。 接続が確立されない場合、中断のない機能を確保するには 2 つの解決策が考えられます。 最初のオプションは、Azure Relay エンドポイントをファイアウォールの許可リスト Get URL of Azure Relay に追加することです。 あるいは、自己完結型のインタラクティブな編集を有効にすることもできます。

Azure Relay の URL の取得

ファイアウォールの許可リストに含める必要がある 1 つの必須ドメインとポートは、Azure Relay との通信用です。 それはセルフホステッド統合ランタイムによって、テスト接続、フォルダー リストやテーブル リストの参照、スキーマの取得、データのプレビューなどのインタラクティブな作成に使用されます。 .servicebus.windows.net を許可せずに、より具体的な URL を使用する必要がある場合は、セルフホステッド統合ランタイムに必要なすべての FQDN をサービス ポータルから確認できます。

UI を使用して Azure Relay の URL を取得する:

次のステップを実行します。

1. サービス ポータルに移動し、セルフホステッド統合ランタイムを選択します。

2. [編集] ページで [ノード] を選択します。

3. [View Service URLs](サービスの URL を表示) を選択して、すべての FQDN を取得します。

   

4. これらの FQDN をファイアウォール規則の許可リストに追加できます。

スクリプトを使用して Azure Relay の URL を取得する:

# The documentation of Synapse self hosted integration runtime (SHIR) mentions that the SHIR requires access to the Azure Service Bus IP addresses
# https://learn.microsoft.com/en-us/azure/data-factory/create-self-hosted-integration-runtime
# It is a requirement to use a wildcard (*.servicebus.windows.net) in your firewalls.
# While this is the easiest way to clear the firewall, it also opens the firewall to all Azure Service Bus IP addresses, including malicious_actor.servicebus.windows.net.
# This might be restricted by your security policies.
# This script resolves the Azure Service Bus IP addresses used by an integration runtime and adds them to the network security group (NSG) rule for the Synapse self-hosted integration runtime (SHIR).
# As the mapping of IP addresses to Domain Names might change, we recommend to run at least once a day to keep the NSG up to date.
# An alternative to running this script is to use the "Self-contained interactive authoring" feature of the self hosted integration runtime.

# Prerequisites:
# - PowerShell installed
# - Azure CLI (az) installed and logged in (https://learn.microsoft.com/en-us/cli/azure/)
# - signed in user needs rights to modify NSG (e.g. Network contributor) and to read status of the SHIR (e.g. reader), plus reader on the subscription

param (
    [string]$synapseRresourceGroupName = "synapse_test",
    [string]$nsgResourceGroupName = "adf_shir_rg",
    [string]$synapseWorkspaceName = "synapse-test-jugi2",
    [string]$integrationRuntimeName = "IntegrationRuntime2",
    [string]$networkSecurityGroupName = "jugis-shir-nsg",
    [string]$securityRuleName = "AllowSynapseServiceBusIPs",
    [int]$priority = 100
)

# Check if the user is already logged in
$azAccount = az account show 2>$null

if (-not $azAccount) {
    # Run az login with managed identity if not logged in
    az login --identity
}

# Retrieve the URLs of the connections from the Synapse self-hosted integration runtime
$urls = az synapse integration-runtime get-status `
    --resource-group $synapseResourceGroupName `
    --workspace-name $synapseWorkspaceName `
    --name $integrationRuntimeName `
    --query "properties.serviceUrls" -o tsv

# Initialize an empty array to hold the IP addresses
$ipAddresses = @()

# Iterate over the URLs to resolve and collect the IP addresses
# The proper DNS resolution might only work within Azure, not locally
foreach ($url in $urls) {
    Write-Output "Processing URL: $url"
    $ip = [System.Net.Dns]::GetHostAddresses($url) | Where-Object { $_.AddressFamily -eq 'InterNetwork' } | Select-Object -ExpandProperty IPAddressToString
    if ($ip) {
        $ipAddresses += $ip
    }
}

# Remove duplicate IP addresses from the array
$ipAddresses = $ipAddresses | Sort-Object -Unique

# Convert the array of IP addresses to a space-separated string
$ipAddressesString = $ipAddresses -join ' '

# Create or update the network security group rule to allow outbound traffic for the collected IP addresses
# Using Invoke-Expression to handle the command string
$az_cmd = "az network nsg rule create --resource-group $nsgResourceGroupName --nsg-name $networkSecurityGroupName --name $securityRuleName --priority $priority --destination-address-prefixes $ipAddressesString --destination-port-ranges '443' --direction Outbound --access Allow --protocol '*' --description 'Allow outbound access to Synapse servicebus IPs'"
Invoke-Expression $az_cmd

ソースからシンクへのデータのコピー

ファイアウォール ルールを、企業ファイアウォール、セルフホステッド統合ランタイム コンピューター上の Windows ファイアウォール、およびデータ ストア自体に対して確実に正しく有効にします。 このルールを有効にすると、セルフホステッド統合ランタイムは、ソースとシンクの両方に正常に接続されます。 コピー操作に関連するデータ ストアごとにルールを有効にしてください。

たとえば、 オンプレミスのデータ ストアから SQL Database シンクまたは Azure Synapse Analytics シンクにコピーするには、以下の手順を実行します。

1. 送信 TCP 通信を、Windows ファイアウォールと企業ファイアウォールの両方に対して、ポート 1433 上で許可します。
2. SQL Database のファイアウォール設定を、セルフホステッド統合ランタイム コンピューターの IP アドレスを許可された IP アドレスのリストに追加するように構成します。

データ ソース、シンク、セルフホステッド統合ランタイムがすべてオンプレミス環境にある場合、コピーされたデータはクラウドに移動せず、厳密にオンプレミス内に残ります。

資格情報ストア

セルフホステッド統合ランタイムを使用する場合、資格情報を格納する方法は 2 つあります。

1. Azure Key Vault を使用します。

これは、Azure に資格情報を格納する場合にお勧めの方法です。 セルフホステッド統合ランタイムは、Azure Key Vault から資格情報を直接取得できます。これにより、潜在的なセキュリティの問題や、セルフホステッド統合ランタイム ノード間の同期中の問題をほぼ回避することができます。 2.資格情報をローカルに保存します。

資格情報は、セルフホステッド統合ランタイムのマシンにプッシュされ、暗号化されます。 セルフホステッド統合ランタイムがクラッシュから回復した場合は、前にバックアップした資格情報から資格情報を回復するか、リンク サービスを編集して、資格情報をセルフホステッド統合ランタイムに再度プッシュすることができます。 そうしないと、セルフホステッド統合ランタイムを使用して実行する際に資格情報が不足するためにパイプラインが機能しません。

インストールのベスト プラクティス

セルフホステッド統合ランタイムのインストールは、マネージド ID セットアップ パッケージを Microsoft ダウンロード センターからダウンロードして実行できます。 詳細な手順については、オンプレミスとクラウドの間でのデータ移動に関する記事を参照してください。

• コンピューターが休止状態にならないように、セルフホステッド統合ランタイム用のホスト コンピューターの電源プランを構成します。 ホスト コンピューターが休止状態になると、セルフホステッド統合ランタイムはオフラインになります。
• 定期的に、セルフホステッド統合ランタイムに関連付けられている資格情報をバックアップします。
• セルフホステッド IR の設定操作を自動化する方法については、PowerShell を使用した既存のセルフホステッド IR の設定に関するページを参照してください。

重要な考慮事項

セルフホステッド統合ランタイムをインストールするときは、次のことを考慮してください

• データ ソースの近くにしますが、必ずしも同じコンピューター上に置く必要はありません
• Power BI ゲートウェイと同じコンピューターにインストールしないでください
• Windows Server のみ (FIPS 準拠の暗号化サーバーでは、ジョブが失敗する可能性があります)
• 複数のデータ ソース間で共有します
• 複数のデータ ファクトリ間で共有します

関連するコンテンツ

詳細な手順については、チュートリアル:オンプレミスのデータをクラウドにコピーする