자체 호스팅 통합 런타임 만들기 및 구성

아티클
09/03/2024

적용 대상: Azure Data Factory Azure Synapse Analytics

팁

기업용 올인원 분석 솔루션인 Microsoft Fabric의 Data Factory를 사용해 보세요. Microsoft Fabric은 데이터 이동부터 데이터 과학, 실시간 분석, 비즈니스 인텔리전스 및 보고에 이르기까지 모든 것을 다룹니다. 무료로 새 평가판을 시작하는 방법을 알아봅니다!

IR(통합 런타임)은 서로 다른 네트워크 환경에서 데이터 통합 기능을 제공하기 위해 Azure Data Factory와 Synapse 파이프라인에서 사용하는 컴퓨팅 인프라입니다. IR에 대한 세부 정보는 통합 런타임 개요를 참조하세요.

자체 호스팅 통합 런타임은 클라우드 데이터 저장소와 개인 네트워크의 데이터 저장소 간에 복사 작업을 실행할 수 있습니다. 또한 온-프레미스 네트워크 또는 Azure 가상 네트워크의 컴퓨팅 리소스에 대해 변환 작업을 디스패치할 수 있습니다. 자체 호스팅 통합 런타임을 설치하려면 온-프레미스 머신이나 개인 네트워크 내부의 가상 머신이 필요합니다.

이 문서에서는 자체 호스팅 IR을 만들고 구성하는 방법을 설명합니다.

참고 항목

Azure Az PowerShell 모듈을 사용하여 Azure와 상호 작용하는 것이 좋습니다. 시작하려면 Azure PowerShell 설치를 참조하세요. Az PowerShell 모듈로 마이그레이션하는 방법에 대한 자세한 내용은 Azure PowerShell을 AzureRM에서 Azure로 마이그레이션을 참조하세요.

자체 호스팅 IR 사용을 위한 고려 사항

단일 자체 호스팅 통합 런타임을 여러 온-프레미스 데이터 원본에 사용할 수 있습니다. 동일한 Microsoft Entra 테넌트 내에서 다른 데이터 팩터리에 공유할 수도 있습니다. 자세한 내용은 자체 호스팅 통합 런타임 공유를 참조하세요.
각 머신에는 자체 호스팅 통합 런타임 인스턴스를 하나씩만 설치할 수 있습니다. 온-프레미스 데이터 원본에 액세스해야 하는 데이터 팩터리 두 개가 있는 경우 자체 호스팅 IR 공유 기능을 사용하여 자체 호스팅 IR을 공유하거나 각 데이터 팩터리 또는 Synapse 작업 영역에 대해 하나씩, 온-프레미스 컴퓨터 두 개에 자체 호스팅 IR을 설치합니다. Synapse 작업 영역은 Integration Runtime 공유를 지원하지 않습니다.
자체 호스팅 통합 런타임이 데이터 원본과 같은 머신에 있을 필요는 없습니다. 그러나 자체 호스팅 통합 런타임이 데이터 원본에 가까우면, 데이터 원본에 연결하는 시간이 줄어듭니다. 온-프레미스 데이터 원본을 호스트하는 머신과 다른 머신에 자체 호스팅 통합 런타임을 설치하는 것이 좋습니다. 자체 호스팅 통합 런타임과 데이터 원본이 서로 다른 머신에 있으면, 자체 호스팅 통합 런타임과 데이터 원본 간에 리소스 경합이 발생하지 않습니다.
서로 다른 컴퓨터의 여러 자체 호스팅 통합 런타임이 동일한 온-프레미스 데이터 원본에 연결할 수 있습니다. 예를 들어, 두 개의 데이터 팩터리를 제공하는 자체 호스팅 통합 런타임이 두 개 있는 경우, 두 데이터 팩터리에 동일한 온-프레미스 데이터 원본을 등록할 수 있습니다.
자체 호스팅 통합 런타임을 사용하여 Azure 가상 네트워크 내에서 데이터 통합을 지원합니다.
Azure ExpressRoute를 사용하더라도 데이터 원본은 방화벽으로 보호되는 온-프레미스 데이터 원본으로 취급해야 합니다. 자체 호스팅 통합 런타임을 사용하여 서비스를 데이터 원본에 연결합니다.
Azure Infrastructure as a Service(IaaS) 가상 머신의 클라우드에 데이터 저장소가 있더라도 자체 호스팅 통합 런타임을 사용합니다.
FIPS 규격 암호화를 사용하는 Windows 서버에 설치한 자체 호스팅 통합 런타임에서는 작업이 실패할 수 있습니다. 이 문제를 해결하려면 Azure Key Vault에 자격 증명/비밀 값 저장하기 또는 서버에서 FIPS 규격 암호화 사용하지 않기 등 두 가지 옵션이 있습니다. FIPS 규격 암호화를 사용하지 않도록 설정하려면 HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled 레지스트리 하위 키의 값을 1(사용)에서 0(사용 안 함)으로 변경합니다. 자체 호스팅 통합 런타임을 SSIS 통합 런타임을 위한 프록시로 사용하는 경우 FIPS 규격 암호화를 사용하도록 설정할 수 있습니다. FIPS 규격 암호화는 온-프레미스에서 Azure Blob Storage 준비 영역으로 데이터를 이동할 때 사용됩니다.
전체 라이선스 세부 정보는 자체 호스팅 통합 런타임 설정의 첫 페이지에 제공됩니다.

참고 항목

현재 자체 호스팅 통합 런타임은 여러 데이터 팩터리와만 공유할 수 있으며, Synapse 작업 영역 또는 데이터 팩터리와 Synapse 작업 영역 간에 공유할 수 없습니다.

명령 흐름 및 데이터 흐름

온-프레미스와 클라우드 간에 데이터를 이동하는 경우 이 작업은 자체 호스팅 통합 런타임을 사용하여 온-프레미스 데이터 원본과 클라우드 간에 데이터를 전송합니다.

다음은 자체 호스팅 IR로 복사 시 데이터 흐름 단계를 대략적으로 요약한 것입니다.

데이터 흐름에 대한 대략적인 개요

데이터 개발자는 먼저 Azure Portal 또는 PowerShell cmdlet을 사용하여 Azure Data Factory 또는 Synapse 작업 영역 내에서 자체 호스팅 통합 런타임을 생성합니다. 그런 다음, 데이터 개발자는 온-프레미스 데이터 저장소에 대한 연결된 서비스를 만들어 서비스가 데이터 저장소에 연결하는 데 사용해야 하는 자체 호스팅 통합 런타임 인스턴스를 지정합니다.
자체 호스팅 통합 런타임 노드가 Windows DPAPI(데이터 보호 응용 프로그래밍 인터페이스)를 사용하여 자격 증명을 암호화하고 로컬에 저장합니다. 고가용성을 위해 여러 노드가 설정된 경우 자격 증명이 다른 노드 간에 동기화됩니다. 각 노드는 DPAPI를 사용하여 자격 증명을 암호화하고 로컬에 저장합니다. 자격 증명 동기화는 데이터 개발자에게는 표시되지 않으며, 자체 호스팅 IR에서 처리됩니다.
Azure Data Factory와 Synapse 파이프라인은 자체 호스팅 통합 런타임과 통신하여 작업을 예약하고 관리합니다. 통신은 공유된 Azure Relay 연결을 사용하는 컨트롤 채널을 통해 전달됩니다. 작업이 실행되어야 할 경우, 서비스는 자격 증명 정보와 함께 요청을 큐에 보관합니다. 이는 자격 증명이 자체 호스팅 통합 런타임에 아직 저장되지 않은 경우에 발생합니다. 자체 호스팅 통합 런타임은 큐를 폴링한 후 작업을 시작합니다.
자체 호스팅 통합 런타임은 온-프레미스 저장소와 클라우드 스토리지 간에 데이터를 복사합니다. 복사 방향은 데이터 파이프라인에서 복사 작업을 구성하는 방법에 따라 달라집니다. 이 단계에서 자체 호스팅 통합 런타임은 안전한 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개, 8GB RAM 및 80GB 여유가 있는 하드 드라이브 공간을 포함하는 2GHz 프로세서입니다. 시스템 요구 사항에 대한 세부 정보는 다운로드를 참조하세요.
호스트 머신이 최대 절전 모드로 전환된 경우, 자체 호스팅 통합 런타임이 데이터 요청에 응답하지 않습니다. 따라서 자체 호스팅 통합 런타임을 설치하기 전에 컴퓨터에서 전원 관리 옵션을 적절하게 구성하세요. 머신이 최대 절전 모드로 전환된 경우, 자체 호스팅 통합 런타임 설치 관리자가 메시지를 표시합니다.
자체 호스팅 통합 런타임을 성공적으로 설치 및 구성하기 위해서는 머신의 관리자여야 합니다.
복사 작업 실행은 특정 빈도로 발생합니다. 머신의 프로세서 및 RAM 사용량은 최대 및 유휴 시간과 동일한 패턴을 따릅니다. 리소스 사용률은 대부분 이동하는 데이터 양에 따라 달라집니다. 여러 복사 작업이 진행 중인 경우 사용량이 많은 시간 동안 리소스 사용량이 증가하는 것을 볼 수 있습니다.
Parquet, ORC 또는 Avro 형식의 데이터를 추출하는 동안 작업이 실패할 수 있습니다. Parquet에 대한 자세한 내용은 Azure Data Factory Parquet 형식을 참조하세요. 파일 생성은 자체 호스팅 통합 머신에서 실행됩니다. 정상적으로 작동하기 위해 파일을 만들려면 다음 필수 구성 요소가 필요합니다.
- JRE 공급자(예: Microsoft OpenJDK 11 또는 Eclipse Temurin 11)의 Java Runtime(JRE) 버전 11 JAVA_HOME 시스템 환경 변수가 JRE 폴더뿐만 아니라 JDK 폴더로 설정되어 있는지 확인합니다. bin 폴더를 시스템의 PATH 환경 변수에 추가해야 할 수도 있습니다.
참고 항목

Parquet 형식 설명서에 설명된 대로 메모리 오류가 발생하는 경우 Java 설정을 조정해야 할 수 있습니다.

참고 항목

정부 클라우드에서 실행하는 경우, 정부 클라우드에 연결을 검토하세요.

자체 호스팅 통합 런타임 설정

자체 호스팅 통합 런타임을 만들고 설정하려면 다음 프로시저를 따르세요.

Azure PowerShell을 사용하여 자체 호스팅 IR 만들기

작업에 Azure PowerShell를 사용할 수 있습니다. 예를 들어 다음과 같습니다.

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

로컬 컴퓨터에서 자체 호스팅 통합 런타임을 다운로드하여 설치합니다.

인증 키를 검색한 다음 해당 키를 사용하여 자체 호스팅 통합 런타임을 등록합니다. 다음은 PowerShell 예제입니다.


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

참고 항목

Azure Government에서 PowerShell 명령을 실행합니다. PowerShell을 사용하여 Azure Government에 연결을 참조하세요.

UI를 통해 자체 호스팅 IR 만들기

다음 단계에 따라 Azure Data Factory 또는 Azure Synapse UI를 사용하여 자체 호스팅 IR을 생성합니다.

Azure Data Factory
Azure Synapse

Azure Data Factory UI의 홈페이지에서 맨 왼쪽 창에 있는 관리 탭을 선택합니다.
왼쪽 창에서 통합 런타임을 선택한 다음, +새로 만들기를 선택합니다.
통합 런타임 설치 페이지에서 Azure, 자체 호스트를 선택하고 계속을 선택합니다.
다음 페이지에서 자체 호스팅을 선택하여 자체 호스팅 IR을 만든 다음, 계속을 선택합니다.

UI를 통해 자체 호스팅 IR 구성

IR의 이름을 입력하고 생성을 선택합니다.
통합 런타임 설치 페이지에서 옵션 1 아래의 링크를 선택하여 컴퓨터에서 기본 설치를 엽니다. 또는 옵션 2의 단계에 따라 수동으로 설정합니다. 다음 지침은 수동 설치를 기준으로 합니다.
1. 인증 키를 복사하여 붙여넣습니다. 통합 런타임 다운로드 및 설치를 선택합니다.
2. 로컬 Windows 컴퓨터에 자체 호스팅된 통합 런타임을 다운로드합니다. 설치 관리자를 실행합니다.
3. 통합 런타임(자체 호스팅) 등록 페이지에서 이전에 저장한 키를 붙여넣고 등록을 선택합니다.
4. 새 통합 런타임(자체 호스팅) 노드 페이지에서 마침을 선택합니다.
자체 호스팅 통합 런타임이 성공적으로 등록되면 다음 창이 표시됩니다.

Azure Resource Manager 템플릿을 사용하여 Azure VM에 자체 호스팅 IR 설정

자체 호스트 IR 템플릿 만들기를 사용하여 Azure 가상 머신에서 자체 호스팅 IR 설정을 자동화할 수 있습니다. 이 템플릿은 Azure 가상 네트워크 내에서 완전히 작동하는 자체 호스팅 IR을 제공하는 쉬운 방법을 제공합니다. IR은 노드 수를 2 이상으로 설정하는 경우 고가용성 및 확장성 기능을 제공합니다.

로컬 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>`"]	현재 노드에서 원격 액세스를 사용하도록 설정하여 고가용성 클러스터를 설정합니다. 또는 Azure Data Factory 또는 Azure Synapse 작업 영역을 거치지 않고 자체 호스팅 IR에 대해 직접 자격 증명 설정을 사용할 수 있습니다. 후자는 동일한 네트워크에 있는 원격 머신에서 New-AzDataFactoryV2LinkedServiceEncryptedCredential cmdlet을 사용하여 수행합니다.
`-erac`, `-EnableRemoteAccessInContainer`	"`<port>`" ["`<thumbprint>`"]	노드가 컨테이너에서 실행될 때 현재 노드에 대한 원격 액세스를 사용하도록 설정합니다.
`-dra`, `-DisableRemoteAccess`		현재 노드에 대한 원격 액세스를 사용하지 않도록 설정합니다. 다중 노드 설정에는 원격 액세스가 필요합니다. New-AzDataFactoryV2LinkedServiceEncryptedCredential PowerShell cmdlet은 원격 액세스를 사용하지 않도록 설정된 경우에도 계속 작동합니다. 이 동작은 cmdlet이 자체 호스팅 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 노드에서 로컬 컴퓨터 액세스(localhost, 개인 IP)를 사용하도록 설정합니다. 자체 호스팅 IR 고가용성 시나리오에서는 모든 자체 호스팅 IR 노드에서 작업을 호출해야 합니다.
`-dlma`, `-DisableLocalMachineAccess`		현재 자체 호스팅 IR 노드에서 로컬 컴퓨터 액세스(localhost, 개인 IP)를 사용하지 않도록 설정합니다. 자체 호스팅 IR 고가용성 시나리오에서는 모든 자체 호스팅 IR 노드에서 작업을 호출해야 합니다.
`-DisableLocalFolderPathValidation`		로컬 컴퓨터의 파일 시스템에 액세스할 수 있도록 하려면 보안 유효성 검사를 사용하지 않도록 설정합니다.
`-EnableLocalFolderPathValidation`		로컬 컴퓨터의 파일 시스템에 액세스할 수 없도록 하려면 보안 유효성 검사를 사용하도록 설정합니다.
`-eesp`, `-EnableExecuteSsisPackage`		자체 호스팅 IR 노드에서 SSIS 패키지 실행을 사용하도록 설정합니다.
`-desp`, `-DisableExecuteSsisPackage`		자체 호스팅 IR 노드에서 SSIS 패키지 실행을 사용하지 않도록 설정합니다.
`-gesp`, `-GetExecuteSsisPackage`		자체 호스팅 IR 노드에서 ExecuteSsisPackage 옵션을 사용하도록 설정한 경우 값을 가져옵니다. 반환된 값이 true이면 ExecuteSSISPackage가 사용하도록 설정되고, 반환된 값이 false 또는 null이면 ExecuteSSISPackage가 사용하지 않도록 설정됩니다.

Microsoft Download Center에서 자체 호스팅 IR 설치 및 등록

Microsoft 통합 런타임 다운로드 페이지로 이동합니다.
다운로드를 선택하고, 64비트 버전을 선택한 후 다음을 선택합니다. 32 비트 버전은 지원되지 않습니다.
MSI 파일을 직접 실행하거나 하드 드라이브에 저장한 후에 실행합니다.
시작 페이지에서 언어를 선택하고, 다음을 선택합니다.
Microsoft 소프트웨어 사용 조건에 동의하고 다음을 선택합니다.
자체 호스팅 통합 런타임을 설치할 폴더를 선택하고 다음을 선택합니다.
설치 준비 완료 페이지에서 설치를 선택합니다.
마침을 선택하여 설치를 완료합니다.

PowerShell을 사용하여 인증 키를 가져옵니다. 인증 키 검색을 위한 PowerShell 예제는 다음과 같습니다.

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

사용자의 머신에서 실행되는 Microsoft 통합 런타임 구성 관리자의 통합 런타임(자체 호스팅) 등록 창에서 다음 단계를 수행합니다.
1. 텍스트 영역에 인증 키를 붙여넣습니다.
2. 필요에 따라 인증 키 표시를 선택하여 키 텍스트를 확인합니다.
3. 등록을 선택합니다.

참고 항목

릴리스 정보는 동일한 Microsoft Integration Runtime 다운로드 페이지에서 사용할 수 있습니다.

자체 호스팅 통합 런타임 서비스 계정

자체 호스팅 통합 런타임의 기본 로그온 서비스 계정은 NT SERVICE\DIAHostService입니다. 서비스 -> 통합 런타임 서비스 -> 속성 -> 로그온에서 볼 수 있습니다.

자체 호스팅 통합 런타임 서비스 계정

계정에 서비스로 로그온 권한이 있는지 확인합니다. 그렇지 않으면, 자체 호스팅 통합 런타임을 성공적으로 시작할 수 없습니다. 로컬 보안 정책 -> 보안 설정 -> 로컬 정책 -> 사용자 권한 할당 -> 서비스로 로그온에서 권한이 있는지 확인할 수 있습니다.

로컬 보안 정책 - 사용자 권한 할당의 스크린샷

서비스로 로그온 사용자 권한 할당의 스크린샷

알림 영역 아이콘 및 알림

알림 영역에서 아이콘이나 메시지 위로 커서를 이동하면 자체 호스팅 통합 런타임의 상태에 대한 세부 정보를 볼 수 있습니다.

알림 영역의 알림

고가용성 및 확장성

자체 호스팅 통합 런타임을 다수의 온-프레미스 머신 또는 Azure의 가상 머신과 연결할 수 있습니다. 이러한 컴퓨터를 노드라고 합니다. 최대 4개의 노드를 자체 호스팅 통합 런타임에 연결할 수 있습니다. 논리 게이트웨이에 게이트웨이가 설치된 온-프레미스 머신에서 다수의 노드를 사용할 경우 다음 이점을 얻을 수 있습니다.

자체 호스팅 통합 런타임의 고가용성 덕분에 빅 데이터 솔루션 또는 클라우드 데이터 통합에서 더 이상 단일 실패 지점이 발생하지 않습니다. 이 가용성은 최대 4 개의 노드를 사용하는 경우 연속성을 보장하는 데 도움이 됩니다.
온-프레미스 및 클라우드 데이터 저장소 간의 데이터 이동 성능 및 처리량을 향상시킵니다. 자세한 내용은 성능 비교를 참조하세요.

다운로드 센터에서 자체 호스팅 통합 런타임 소프트웨어를 설치하여 여러 노드를 연결할 수 있습니다. 그런 다음 자습서의 설명에 따라 New-AzDataFactoryV2IntegrationRuntimeKey cmdlet에서 가져온 인증 키 중 하나를 사용하여 등록합니다.

참고 항목

각 노드에 연결하기 위해 자체 호스팅 통합 런타임을 새로 만들 필요는 없습니다. 자체 호스팅 통합 런타임을 다른 컴퓨터에서 설치하고 동일한 인증 키를 사용하여 등록할 수 있습니다.

참고 항목

고가용성과 확장성을 위해 다른 노드를 추가하기 전에 첫 번째 노드에서 인트라넷에 원격 액세스 옵션이 사용하도록 설정되어 있는지 확인합니다. 이렇게 하려면 Microsoft Integration Runtime Configuration Manager > 설정 > 인트라넷에 원격 액세스를 선택합니다.

크기 조정 고려 사항

확장

프로세서 사용량이 많고 자체 호스팅 IR에서 사용 가능한 메모리가 부족한 경우 머신 간에 로드를 스케일 아웃하는 데 도움이 되는 새 노드를 추가합니다. 시간이 초과되거나 자체 호스팅 IR 노드가 오프라인 상태여서 작업이 실패하는 경우 게이트웨이에 노드를 추가하면 도움이 됩니다. 노드를 추가하려면 다음 단계를 완료합니다.

Azure Data Factory 포털 SHIR 설치 프로그램을 다운로드합니다.
클러스터에 추가하려는 노드에서 설치 관리자를 실행합니다.
설치하는 동안 기존 통합 런타임에 조인하는 옵션을 선택하고 기존 SHIR의 인증 키를 제공하여 새 노드를 기존 SHIR 클러스터에 연결합니다.

강화

프로세서 및 사용 가능한 RAM이 잘 활용되지 않는데도 동시 작업 실행이 노드의 제한에 도달하면 노드가 실행할 수 있는 동시 작업 수를 스케일 업합니다. 또한 자체 호스팅 IR 오버로드로 인해 활동 시간이 초과되는 경우에도 스케일 업할 수 있습니다. 다음 이미지와 같이 노드의 최대 용량을 늘릴 수 있습니다.

노드에서 실행할 수 있는 동시 작업 수 늘리기

TLS/SSL 인증서 요구 사항

TLS/SSL 인증서(고급)를 사용하여 인트라넷에서 원격 액세스를 활성화하여 통합 런타임 노드 간의 통신을 보호하려는 경우 TLS/SSL 인증서를 사용하여 인트라넷에서 원격 액세스 활성화의 단계를 수행할 수 있습니다.

참고 항목

이 인증서는 다음 경우에 사용됩니다.

자체 호스팅 IR 노드의 포트를 암호화합니다.
상태 동기화에 대한 노드 간 통신의 경우 노드 간 연결된 서비스의 자격 증명 동기화를 포함합니다.
PowerShell cmdlet이 로컬 네트워크 내에서 연결된 서비스 자격 증명 설정에 사용되는 경우

프라이빗 네트워크 환경이 안전하지 않거나 프라이빗 네트워크 내에서 노드 간의 통신을 보호하려는 경우에 이 인증서를 사용하는 것이 좋습니다.

자체 호스팅 IR에서 다른 데이터 저장소로 전송되는 데이터 이동은 이 인증서의 설정 여부와 관계없이 항상 암호화된 채널 내에서 이루어집니다.

자격 증명 동기화

자격 증명 또는 비밀 값을 Azure Key Vault 저장하지 않으면 자격 증명 또는 암호 값이 자체 호스팅 통합 런타임이 있는 컴퓨터에 저장됩니다. 각 노드에는 특정 버전의 자격 증명 복사본이 있습니다. 모든 노드가 함께 작동하도록 하려면, 모든 노드에 대해 버전 번호가 동일해야 합니다.

프록시 서버 고려 사항

회사 네트워크 환경에서 프록시 서버를 사용하여 인터넷에 액세스하는 경우 자체 호스팅 통합 런타임이 적절한 프록시 설정을 사용하도록 구성합니다. 초기 등록 단계에서 프록시를 설정할 수 있습니다.

프록시 서버 지정

구성된 경우 자체 호스팅 통합 런타임은 프록시 서버를 사용하여 클라우드 서비스의 원본 및 대상(HTTP 또는 HTTPS 프로토콜 사용)에 연결합니다. 초기 설치 시 변경 링크를 선택해야 하는 이유입니다.

프록시 설정

이 대화 상자에는 세 가지 구성 옵션이 있습니다.

프록시 사용 안 함: 자체 호스팅 통합 런타임을 클라우드 서비스에 연결하는 데는 프록시를 명시적으로 사용하지 않습니다.
시스템 프록시 사용: 자체 호스팅 통합 런타임은 diahost.exe.config 및 diawp.exe.config에 구성된 프록시 설정을 사용합니다. 해당 파일에 프록시 구성이 지정되어 있지 않으면 자체 호스팅 통합 런타임은 프록시를 거치지 않고 클라우드 서비스에 직접 연결합니다.
사용자 지정 프록시 사용: diahost.exe.config 및 diawp.exe.config의 구성을 사용하는 대신 자체 호스팅 통합 런타임에 사용할 HTTP 프록시 설정을 구성합니다. 주소 및 포트 값이 필요합니다. 사용자 이름과 암호는 프록시 인증 설정에 따른 선택 사항입니다. 모든 설정은 자체 호스팅 통합 런타임d에서 Windows DPAPI를 사용하여 암호화되며 컴퓨터에 로컬로 저장됩니다.

업데이트된 프록시 설정을 저장하면, 통합 런타임 호스트 서비스가 자동으로 다시 시작됩니다.

자체 호스팅 통합 런타임을 등록한 후 프록시 설정을 확인하거나 업데이트하려면 Microsoft 통합 런타임 구성 관리자를 사용합니다.

Microsoft 통합 런타임 구성 관리자를 엽니다.
설정 탭을 선택합니다.
HTTP 프록시에서 변경링크를 선택하여 HTTP 프록시 설정 대화 상자를 엽니다.
다음을 선택합니다. 그러면 프록시 설정이 저장되고 통합 런타임 호스트 서비스를 다시 시작하기 위한 권한이 필요하다는 경고가 표시됩니다.

구성 관리자 도구를 사용하여 HTTP 프록시를 확인하고 업데이트할 수 있습니다.

프록시 보기 및 업데이트

참고 항목

NTLM 인증을 사용하여 프록시 서버를 설정하면 통합 런타임 호스트 서비스가 도메인 계정에서 실행됩니다. 나중에 도메인 계정 암호를 변경하는 경우에는 서비스의 구성 설정을 업데이트하여 서비스를 다시 시작해야 합니다. 이 요구 사항으로 인해 암호를 자주 업데이트하지 않아도 되는 전용 도메인 계정을 사용하여 프록시 서버에 액세스하는 것이 좋습니다.

프록시 서버 설정 구성

HTTP 프록시에 대해 시스템 프록시 사용 옵션을 선택하는 경우 자체 호스팅 통합 런타임은 diahost.exe.config 및 diawp.exe.config의 프록시 설정을 사용합니다. 이러한 파일에 프록시가 지정되지 않은 경우 자체 호스팅 통합 런타임은 프록시를 거치지 않고 클라우드 서비스에 직접 연결합니다. 다음 절차에서는 diahost.exe.config 파일을 업데이트하는 지침을 제공합니다.

파일 탐색기에서 원본 파일을 백업할 C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config의 안전한 복사본을 만듭니다.
관리자 권한으로 메모장 열기.
관리자 권한으로 Notepad를 열고 텍스트 파일 C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config를 엽니다.

다음 코드에 표시된 것처럼 기본 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 "/>

구성 파일을 원래 위치에 저장 자체 호스팅 통합 런타임 호스트 서비스를 다시 시작할 경우, 변경 내용이 적용됩니다.

서비스를 다시 시작하려면, 제어판에서 서비스 애플릿을 사용합니다. 또는 통합 런타임 구성 관리자에서 서비스 중지 단추를 선택한 후 서비스 시작을 선택합니다.

서비스가 시작되지 않으면 편집한 애플리케이션 구성 파일에 잘못된 XML 태그 구문이 추가되었을 가능성이 높습니다.

Important

diahost.exe.config 및 diawp.exe.config를 둘 다 업데이트해야 합니다.

또한 회사의 허용 목록에 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 파일에 대해 이러한 단계를 반복해야 합니다.

파일 탐색기에서 원본 파일을 백업할 C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config의 안전한 복사본을 만듭니다.
관리자 권한으로 메모장 열기.
메모장에서 C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config를 엽니다.

여기에 나와 있는 것처럼 기본 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 파이프라인에 연결하여 자신을 인증할 수 없습니다. 이전 섹션을 참조하여 방화벽 및 프록시 서버가 올바르게 구성되었는지 확인합니다.

자체 호스팅 통합 런타임을 등록할 때 다음과 같은 오류 메시지가 표시됩니다. "이 통합 런타임 노드를 등록하지 못했습니다. 인증 키가 유효하며 통합 서비스 호스트 서비스가 이 머신에서 실행 중인지 확인하세요."
통합 런타임 구성 관리자를 열 때 상태가 연결 끊김 또는 연결 중으로 표시됩니다. Windows 이벤트 로그를 볼 때 이벤트 뷰어 > 애플리케이션 및 서비스 로그 > Microsoft 통합 런타임에서 다음과 같은 오류 메시지가 표시됩니다.
```
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 cmdlet을 사용할 수 있습니다.

포트 및 방화벽

다음 두 가지 방화벽을 고려해야 합니다.

기업에서는 기업 방화벽이 조직의 중앙 라우터에서 실행됩니다.
또한 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의 경우 자체 호스팅 Integration Runtime 키에서 FQDN(정규화된 도메인 이름)을 찾습니다({data factory} 형식). {region}.datafactory.azure.net. 이전 데이터 팩터리 및 모든 버전의 Azure Synapse Analytics의 경우 자체 호스팅 통합 키에 FQDN이 표시되지 않는 경우 *.frontend.clouddatahub.net 대신 사용합니다.
`download.microsoft.com`	443	업데이트를 다운로드하기 위해 자체 호스팅 통합 런타임에서 필요합니다. 자동 업데이트 기능을 사용하지 않도록 설정한 경우 이 도메인 구성을 건너뛸 수 있습니다.
주요 자격 증명 모음 URL	443	Key Vault에 자격 증명을 저장하는 경우 Azure Key Vault별로 필요합니다.

Windows 방화벽 수준 또는 머신 수준에서 대개 아웃바운드 포트를 사용하도록 설정됩니다. 해당 포트가 사용하도록 설정되어 있지 않으면 자체 호스팅 통합 런타임 머신에서 도메인 및 포트를 구성할 수 있습니다.

참고 항목

현재 Azure Relay 서비스 태그를 지원하지 않으므로 Azure Relay와 통신하려면 NSG 규칙에서 AzureCloud 또는 Internet 서비스 태그를 사용해야 합니다. Azure Data Factory 및 Synapse 작업 영역 통신의 경우, NSG 규칙 설정에서 DataFactoryManagement 서비스 태그를 사용할 수 있습니다.

원본 및 싱크에 따라 회사 방화벽 또는 Windows 방화벽에서 추가 도메인 및 아웃바운드 포트를 허용해야 할 수 있습니다.

도메인 이름	아웃바운드 포트	설명
`*.core.windows.net`	443	단계 복사 기능을 사용할 때 자체 호스팅 통합 런타임에서 Azure Storage 계정에 연결하는 데 사용됩니다.
`*.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 주소를 허용해야 할 수 있습니다.

참고 항목

대부분 Integration Runtime은 Power BI 게이트웨이에서도 사용되는 기본 포트 중 하나인 포트 번호 443을 사용하기 때문에 Integration Runtime 및 Power BI 게이트웨이를 모두 동일한 머신에 설치하는 것은 좋지 않습니다.

자체 포함된 대화형 작성(미리 보기)

데이터 미리 보기 및 연결 테스트와 같은 대화형 작성 작업을 수행하려면 자체 호스팅 통합 런타임에서 Azure Relay에 연결해야 합니다. 연결이 설정되지 않은 경우 중단 없는 기능을 보장하기 위한 두 가지 활용 가능한 솔루션이 있습니다. 첫 번째 옵션은 방화벽의 허용 목록 Azure Relay URL 가져오기에 Azure Relay 엔드포인트를 추가하는 것입니다. 또는 자체 포함 대화형 작성을 사용하도록 설정할 수 있습니다.

참고 항목

자체 호스팅 통합 런타임이 Azure Relay에 대한 연결을 설정하지 못하면 해당 상태가 "제한됨"으로 표시됩니다.

자체 포함된 대화형 작성의 스크린샷.

참고 항목

자체 포함 대화형 작성을 사용하도록 설정하는 동안 모든 대화형 작성 트래픽은 Azure Relay를 우회하여 이 기능을 통해서만 라우팅됩니다. 이 기능을 사용하지 않도록 선택한 후에만 트래픽이 Azure Relay로 다시 리디렉션됩니다.

참고 항목

자체 포함된 대화형 작성이 사용하도록 설정된 경우 "IP 가져오기" 및 "로그 보내기"는 모두 지원되지 않습니다.

Azure Relay URL 가져오기

방화벽의 허용 목록에 배치해야 하는 필수 도메인 및 포트 중 하나는 Azure Relay와의 통신입니다. 자체 호스팅 통합 런타임은 이를 연결 테스트, 폴더 목록 및 테이블 목록 찾아보기, 스키마 가져오기 및 데이터 미리 보기와 같은 대화형 제작에 사용합니다. Servicebus.windows.net을 허용하지 않고 더 구체적인 URL을 포함하려는 경우 서비스 포털에서 자체 호스팅 통합 런타임에 필요한 모든 FQDN을 볼 수 있습니다.

UI를 통해 Azure Relay의 URL을 가져옵니다.

다음 단계를 수행합니다.

서비스 포털로 이동하여 자체 호스팅 통합 런타임을 선택합니다.
편집 페이지에서 노드를 선택합니다.
모든 FQDN을 가져오려면 서비스 URL 보기를 선택합니다.
이 FQDN은 방화벽 규칙 허용 목록에 추가할 수 있습니다.

참고 항목

Azure Relay 연결 프로토콜과 관련된 자세한 내용은 Azure Relay 하이브리드 연결 프로토콜을 참조하세요.

스크립트를 통해 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 싱크로 복사하려면 다음 단계를 수행합니다.

Windows 방화벽 및 회사 방화벽 둘 다에 대해 1433 포트에서 아웃바운드 TCP 통신을 허용합니다.
SQL 데이터베이스의 방화벽 설정을 구성하여 허용된 IP 주소 목록에 자체 호스팅 통합 런타임 머신의 IP 주소를 추가합니다.

참고 항목

방화벽이 아웃바운드 1433 포트를 허용하지 않으면, 자체 호스팅 통합 런타임은 SQL 데이터베이스에 직접 액세스할 수 없습니다. 이 경우 스테이징된 복사본을 사용하여 SQL Database 및 Azure Synapse Analytics를 사용할 수 있습니다. 이 시나리오에서는 데이터 이동에 HTTPS(443 포트)만 필요합니다.

모든 데이터 원본과 싱크 및 자체 호스팅 통합 런타임이 온-프레미스 환경에 있는 경우 복사된 데이터는 클라우드로 이동하지 않고 온-프레미스 내에 엄격하게 유지됩니다.

자격 증명 저장소

자체 호스팅 통합 런타임을 사용할 때 자격 증명을 저장하는 방법에는 두 가지가 있습니다.

Azure Key Vault를 사용합니다.

Azure에 자격 증명을 저장하는 것이 좋습니다. 자체 호스팅 통합 런타임은 Azure Key Vault에서 자격 증명을 직접 가져올 수 있으므로 일부 잠재적인 보안 문제 또는 자체 호스팅 통합 런타임 노드 간의 자격 증명 동기화 내 문제를 크게 방지할 수 있습니다. 2. 자격 증명을 로컬로 저장합니다.

자격 증명은 자체 호스팅 통합 런타임의 머신에 푸시되고 암호화됩니다. 자체 호스팅 통합 런타임이 크래시에서 복구되면 이전에 백업한 자격 증명에서 자격 증명을 복구하거나 연결된 서비스를 편집하고 자격 증명을 자체 호스팅 통합 런타임에 다시 푸시할 수 있습니다. 그렇지 않으면 자체 호스팅 통합 런타임을 통해 실행할 때 자격 증명이 부족하여 파이프라인이 작동하지 않습니다.

참고 항목

자격 증명을 로컬로 저장하려는 경우 대화형 작성을 위한 도메인을 방화벽 허용 목록에 배치하고 포트를 열어야 합니다. 또한 이 채널은 자체 호스팅 통합 런타임이 자격 증명을 가져오기 위한 채널이기도 합니다. 대화형 작성에 필요한 도메인 및 포트의 경우 포트 및 방화벽을 참조하세요.

설치 모범 사례

자체 호스팅 통합 런타임은 Microsoft 다운로드 센터에서 관리 ID 설치 패키지를 다운로드하여 설치할 수 있습니다. 단계별 지침은 온-프레미스 및 클라우드 간 데이터 이동 문서를 참조하세요.

호스트 머신이 최대 절전 모드로 전환되지 않도록 해당 머신에서 자체 호스팅 통합 런타임에 대한 전원 관리 옵션을 구성합니다. 호스트 컴퓨터가 최대 절전 모드로 설정되면 자체 호스팅 통합 런타임도 오프라인 상태가 됩니다.
자체 호스팅 통합 런타임과 연결된 자격 증명을 정기적으로 백업합니다.
자체 호스팅 IR 설치 작업을 자동화하려면 PowerShell을 통해 기존 자체 호스트 IR 설정을 참조하세요.

중요 사항

자체 호스팅 통합 런타임을 설치할 때 다음을 고려합니다.

데이터 원본에 가깝게 유지하지만 반드시 동일한 머신에 있을 필요는 없습니다.
Power BI 게이트웨이와 동일한 머신에 설치하지 마세요.
Windows Server만(FIPS 규격 암호화 서버로 인해 작업이 실패할 수 있음)
여러 데이터 원본에서 공유
여러 데이터 팩터리에서 공유

단계별 지침은 자습서: 온-프레미스 데이터를 클라우드로 복사를 참조하세요.

다음을 통해 공유

자체 호스팅 통합 런타임 만들기 및 구성

자체 호스팅 IR 사용을 위한 고려 사항

명령 흐름 및 데이터 흐름

필수 조건

자체 호스팅 통합 런타임 설정

Azure PowerShell을 사용하여 자체 호스팅 IR 만들기

UI를 통해 자체 호스팅 IR 만들기

UI를 통해 자체 호스팅 IR 구성

Azure Resource Manager 템플릿을 사용하여 Azure VM에 자체 호스팅 IR 설정

로컬 PowerShell을 통해 기존 자체 호스팅 IR 설정하기

Microsoft Download Center에서 자체 호스팅 IR 설치 및 등록

자체 호스팅 통합 런타임 서비스 계정

알림 영역 아이콘 및 알림

고가용성 및 확장성

크기 조정 고려 사항

확장

강화

TLS/SSL 인증서 요구 사항

자격 증명 동기화

프록시 서버 고려 사항

프록시 서버 설정 구성

프라이빗 엔드포인트를 사용할 때 프록시 서버 설정 구성

인트라넷에서 원격 액세스 사용하기

포트 및 방화벽

자체 포함된 대화형 작성(미리 보기)

Azure Relay URL 가져오기

UI를 통해 Azure Relay의 URL을 가져옵니다.

스크립트를 통해 Azure Relay의 URL을 가져옵니다.

원본에서 싱크로 데이터 복사

자격 증명 저장소

설치 모범 사례

중요 사항

피드백

추가 리소스

다음을 통해 공유

자체 호스팅 통합 런타임 만들기 및 구성

자체 호스팅 IR 사용을 위한 고려 사항

명령 흐름 및 데이터 흐름

필수 조건

자체 호스팅 통합 런타임 설정

Azure PowerShell을 사용하여 자체 호스팅 IR 만들기

UI를 통해 자체 호스팅 IR 만들기

UI를 통해 자체 호스팅 IR 구성

Azure Resource Manager 템플릿을 사용하여 Azure VM에 자체 호스팅 IR 설정

로컬 PowerShell을 통해 기존 자체 호스팅 IR 설정하기

Microsoft Download Center에서 자체 호스팅 IR 설치 및 등록

자체 호스팅 통합 런타임 서비스 계정

알림 영역 아이콘 및 알림

고가용성 및 확장성

크기 조정 고려 사항

확장

강화

TLS/SSL 인증서 요구 사항

자격 증명 동기화

프록시 서버 고려 사항

프록시 서버 설정 구성

프라이빗 엔드포인트를 사용할 때 프록시 서버 설정 구성

방화벽 및 프록시 서버와 관련된 문제에서 가능한 증상

인트라넷에서 원격 액세스 사용하기

포트 및 방화벽

자체 포함된 대화형 작성(미리 보기)

Azure Relay URL 가져오기

UI를 통해 Azure Relay의 URL을 가져옵니다.

스크립트를 통해 Azure Relay의 URL을 가져옵니다.

원본에서 싱크로 데이터 복사

자격 증명 저장소

설치 모범 사례

중요 사항

관련 콘텐츠

피드백

추가 리소스