Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
DOTYCZY:
Azure Data Factory
Azure Synapse Analytics
Napiwek
Wypróbuj usługę Data Factory w usłudze Microsoft Fabric — rozwiązanie analityczne typu all-in-one dla przedsiębiorstw. Usługa Microsoft Fabric obejmuje wszystko, od przenoszenia danych do nauki o danych, analizy w czasie rzeczywistym, analizy biznesowej i raportowania. Dowiedz się, jak bezpłatnie rozpocząć nową wersję próbną !
Środowisko Integration Runtime (IR) to infrastruktura obliczeniowa używana przez potoki usługi Azure Data Factory i Synapse w celu zapewnienia możliwości integracji danych w różnych środowiskach sieciowych.
Własne środowisko Integration Runtime zapewnia te możliwości między magazynem danych w chmurze a magazynem danych w sieci prywatnej, na przykład siecią lokalną lub siecią wirtualną platformy Azure. W tym artykule opisano sposób tworzenia i konfigurowania własnego środowiska IR na maszynie w sieci prywatnej, dzięki czemu możesz połączyć źródło danych z zasobami integracji danych.
Uwaga
Do interakcji z platformą Azure zalecamy używanie modułu Azure Az w programie PowerShell. Zobacz Instalowanie programu Azure PowerShell, aby rozpocząć. Aby dowiedzieć się, jak przeprowadzić migrację do modułu Az PowerShell, zobacz Migracja programu Azure PowerShell z modułu AzureRM do modułu Az.
Zagadnienia dotyczące korzystania z własnego środowiska IR
- Możesz użyć jednego własnego środowiska Integration Runtime dla wielu lokalnych źródeł danych. Możesz również udostępnić ją innej fabryce danych w tej samej dzierżawie firmy Microsoft Entra. Aby uzyskać więcej informacji, zobacz Udostępnianie własnego środowiska Integration Runtime.
- Na pojedynczej maszynie można zainstalować tylko jedno wystąpienie własnego środowiska Integration Runtime. Jeśli masz dwie fabryki danych, które muszą uzyskiwać dostęp do lokalnych źródeł danych, użyj funkcji udostępniania własnego środowiska IR, aby udostępnić własne środowisko IR, lub zainstaluj własne środowisko IR na dwóch komputerach lokalnych, po jednym dla każdej fabryki danych lub obszaru roboczego usługi Synapse. Obszar roboczy usługi Synapse nie obsługuje udostępniania środowiska Integration Runtime.
- Własne środowisko Integration Runtime nie musi znajdować się na tej samej maszynie co źródło danych. Jednak posiadanie własnego środowiska Integration Runtime w pobliżu źródła danych skraca czas na połączenie własnego środowiska Integration Runtime ze źródłem danych. Zalecamy zainstalowanie lokalnie hostowanego środowiska integracji runtime na maszynie, która różni się od tej, która hostuje źródło danych lokalnie. Gdy samodzielnie hostowane środowisko uruchomieniowe integracji i źródło danych znajdują się na różnych maszynach, samodzielnie hostowane środowisko uruchomieniowe integracji nie konkuruje ze źródłem danych o zasoby.
- Na różnych maszynach, które łączą się z tym samym lokalnym źródłem danych, możesz mieć wiele własnych środowisk Integration Runtime. Jeśli na przykład masz dwa własne środowiska Integration Runtime, które obsługują dwie fabryki danych, to samo lokalne źródło danych można zarejestrować w obu fabrykach danych.
- Używanie własnego środowiska Integration Runtime do obsługi integracji danych w sieci wirtualnej platformy Azure.
- Traktuj źródło danych jako lokalne źródło danych, które znajduje się za zaporą, nawet jeśli używasz usługi Azure ExpressRoute. Użyj własnego środowiska Integration Runtime, aby połączyć usługę ze źródłem danych.
- Użyj własnego środowiska Integration Runtime hostowanego lokalnie, nawet jeśli magazyn danych znajduje się w chmurze, na maszynie wirtualnej na platformie Azure w modelu infrastruktura jako usługa (IaaS).
- Zadania mogą zakończyć się niepowodzeniem w własnym środowisku Integration Runtime zainstalowanym na serwerze z systemem Windows, dla którego włączono szyfrowanie zgodne ze standardem FIPS. Aby obejść ten problem, masz dwie opcje: przechowywanie poświadczeń/wartości wpisów tajnych w usłudze Azure Key Vault lub wyłączanie szyfrowania zgodnego ze standardem FIPS na serwerze. Aby wyłączyć szyfrowanie zgodne ze standardem FIPS, zmień wartość następującego podklucza rejestru z 1 (włączone) na 0 (wyłączone):
HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled. Jeśli używasz własnego środowiska Integration Runtime jako serwera proxy dla środowiska SSIS Integration Runtime, szyfrowanie zgodne ze standardem FIPS można włączyć i będzie używane podczas przenoszenia danych ze środowiska lokalnego do usługi Azure Blob Storage jako obszaru przejściowego. - Pełne szczegóły licencjonowania znajdują się na pierwszej stronie konfiguracji własnego środowiska Integration Runtime.
Uwaga
Obecnie własne środowisko Integration Runtime może być współużytkowane tylko z wieloma fabrykami danych. Nie można go udostępniać w obszarach roboczych usługi Synapse ani między fabryką danych i obszarem roboczym usługi Synapse.
Przepływ poleceń i przepływ danych
Podczas przenoszenia danych między środowiskiem lokalnym a chmurą działanie używa własnego środowiska Integration Runtime do transferu danych między lokalnym źródłem danych a chmurą.
Poniżej przedstawiono ogólne podsumowanie kroków przepływu danych dotyczących kopiowania przy użyciu własnego środowiska IR:
Deweloper danych najpierw tworzy samodzielnie hostowane środowisko Integration Runtime w usłudze Azure Data Factory lub obszarze roboczym usługi Synapse przy użyciu witryny Azure Portal lub polecenia cmdlet programu PowerShell. Następnie deweloper danych tworzy usługę powiązaną dla lokalnego magazynu danych, określając własnowystarczalną instancję środowiska Integration Runtime, której usługa powinna używać do łączenia się z magazynami danych.
Węzeł własnego środowiska Integration Runtime szyfruje poświadczenia przy użyciu interfejsu programowania aplikacji ochrony danych systemu Windows (DPAPI) i zapisuje poświadczenia lokalnie. Jeśli dla wysokiej dostępności ustawiono wiele węzłów, poświadczenia są dodatkowo synchronizowane między innymi węzłami. Każdy węzeł szyfruje poświadczenia przy użyciu interfejsu DPAPI i przechowuje je lokalnie. Synchronizacja poświadczeń jest przezroczysta dla dewelopera danych i jest obsługiwana przez samodzielnie zarządzane środowisko IR.
Potoki usług Azure Data Factory i Synapse komunikują się z własnym środowiskiem Integration Runtime w celu planowania zadań i zarządzania nimi. Komunikacja odbywa się za pośrednictwem kanału sterowania korzystającego z udostępnionego połączenia usługi Azure Relay . Gdy zadanie działania musi zostać uruchomione, usługa kolejkuje żądanie wraz z wszelkimi informacjami o poświadczeniach. Robi to w przypadku, gdy poświadczenia nie są jeszcze przechowywane we własnym środowisku uruchomieniowym Integration Runtime. Samodzielnie hostowane środowisko Integration Runtime uruchamia zadanie po sondowaniu kolejki.
Własne środowisko Integration Runtime kopiuje dane między magazynem lokalnym i magazynem w chmurze. Kierunek kopiowania zależy od konfiguracji działania kopiowania w potoku danych. W tym kroku własne środowisko Integration Runtime komunikuje się bezpośrednio z usługami magazynu w chmurze, takimi jak Azure Blob Storage za pośrednictwem bezpiecznego kanału HTTPS.
Wymagania wstępne
- Obsługiwane wersje systemu Windows to:
- Windows 10
- Windows 11
- Windows Server 2016
- Windows Server 2019
- Windows Server 2022
- Windows Server 2025
Instalacja własnego środowiska Integration Runtime na kontrolerze domeny nie jest obsługiwana.
- Własne środowisko Integration Runtime wymaga 64-bitowego systemu operacyjnego z programem .NET Framework 4.7.2 lub nowszym. Aby uzyskać szczegółowe informacje, zobacz Wymagania systemowe programu .NET Framework.
- Zalecana minimalna konfiguracja własnego środowiska Integration Runtime to procesor 2 GHz z 4 rdzeniami, 8 GB pamięci RAM i 80 GB dostępnego miejsca na dysku twardym. Aby uzyskać szczegółowe informacje o wymaganiach systemowych, zobacz Pobieranie.
- Jeśli maszyna hosta hibernuje, samoobsługowe środowisko wykonawcze integracji nie odpowiada na żądania danych. Przed zainstalowaniem własnego środowiska Integration Runtime skonfiguruj odpowiedni plan zasilania na komputerze. Jeśli maszyna jest skonfigurowana do hibernacji, instalator własnego środowiska Integration Runtime wyświetli monit z komunikatem.
- Aby pomyślnie zainstalować i skonfigurować własne środowisko Integration Runtime, musisz być administratorem na maszynie.
- Uruchomienia działania kopiowania są wykonywane z określoną częstotliwością. Użycie procesora i pamięci RAM na maszynie jest zgodne z tym samym wzorcem ze szczytowymi i bezczynnymi godzinami. Użycie zasobów zależy również w dużym stopniu od ilości przeniesionych danych. Gdy w toku jest wiele zadań kopiowania, użycie zasobów będzie rosnąć w godzinach szczytu.
- Zadania mogą zakończyć się niepowodzeniem podczas wyodrębniania danych w formatach Parquet, ORC lub Avro. Aby dowiedzieć się więcej na temat Parquet, zobacz Format Parquet w usłudze Azure Data Factory. Tworzenie plików jest uruchamiane na maszynie integracji hostowanej samodzielnie. Aby działać zgodnie z oczekiwaniami, tworzenie pliku wymaga następujących wymagań wstępnych:
- Środowisko Java Runtime (JRE) w wersji 11 od dostawcy środowiska JRE, takiego jak Microsoft OpenJDK 11 lub Eclipse Temurin 11. Upewnij się, że zmienna środowiskowa systemu JAVA_HOME jest ustawiona na folder JDK (nie tylko folder JRE), może być również konieczne dodanie folderu bin do zmiennej środowiskowej PATH systemu.
Uwaga
Jeśli wystąpią błędy pamięci, konieczne może być dostosowanie ustawień Javy, jak opisano w dokumentacji formatu Parquet.
Uwaga
Jeśli korzystasz z chmury dla instytucji rządowych, zapoznaj się z artykułem Łączenie z chmurą dla instytucji rządowych.
Konfigurowanie własnego środowiska Integration Runtime
Aby utworzyć i skonfigurować własne środowisko Integration Runtime, skorzystaj z poniższych procedur.
Tworzenie własnego środowiska IR za pomocą programu Azure PowerShell
W tym zadaniu można użyć programu Azure PowerShell. Oto przykład:
Set-AzDataFactoryV2IntegrationRuntime -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName -Type SelfHosted -Description "selfhosted IR description"Pobierz i zainstaluj własne środowisko Integration Runtime na komputerze lokalnym.
Pobierz klucz uwierzytelniania i zarejestruj lokalne środowisko uruchomieniowe integracji przy użyciu tego klucza. Oto przykład programu PowerShell:
Get-AzDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName
Uwaga
Jeśli korzystasz z chmury dla instytucji rządowych, zapoznaj się z artykułem Łączenie z chmurą dla instytucji rządowych.
Tworzenie własnego środowiska IR za pośrednictwem interfejsu użytkownika
Wykonaj poniższe kroki, aby utworzyć własne środowisko IR przy użyciu usługi Azure Data Factory lub interfejsu użytkownika usługi Azure Synapse.
Na stronie głównej interfejsu użytkownika usługi Azure Data Factory wybierz kartę Zarządzanie w okienku po lewej stronie.
W okienku po lewej stronie wybierz środowiska wykonawcze Integracji, a następnie wybierz +Nowy.
Na stronie Konfiguracja środowiska Integration Runtime wybierz pozycję Azure, Self-Hosted, a następnie wybierz pozycję Kontynuuj.
Na poniższej stronie wybierz pozycję Self-Hosted , aby utworzyć własne środowisko IR, a następnie wybierz pozycję Kontynuuj.
Konfigurowanie własnego środowiska IR za pośrednictwem interfejsu użytkownika
Wprowadź nazwę dla swojego IR i wybierz Utwórz.
Na stronie Konfiguracja środowiska Integration Runtime wybierz link w obszarze Opcja 1, aby otworzyć instalację ekspresową na komputerze. Możesz też wykonać kroki opisane w sekcji Opcja 2 , aby skonfigurować ręcznie. Poniższe instrukcje są oparte na konfiguracji ręcznej:
Skopiuj i wklej klucz uwierzytelniania. Wybierz pozycję Pobierz i zainstaluj środowisko Integration Runtime.
Pobierz lokalne środowisko uruchomieniowe Integration Runtime na komputer lokalny z systemem Windows. Uruchom instalatora.
Na stronie Rejestracja środowiska Integration Runtime (self-hosted) wklej zapisany wcześniej klucz i wybierz opcję Zarejestruj.
Na stronie Integration Runtime (self-hosted) Nowy węzeł, wybierz pozycję Zakończ.
Po pomyślnym zarejestrowaniu własnego środowiska Integration Runtime zostanie wyświetlone następujące okno:
Konfigurowanie własnego środowiska IR na maszynie wirtualnej platformy Azure za pomocą szablonu usługi Azure Resource Manager
Konfigurację własnego środowiska IR można zautomatyzować na maszynie wirtualnej platformy Azure przy użyciu szablonu Tworzenie własnego środowiska IR hosta. Szablon zapewnia łatwy sposób posiadania w pełni funkcjonalnego własnego środowiska IR w sieci wirtualnej platformy Azure. Środowisko IR ma funkcje wysokiej dostępności i skalowalności, o ile liczba węzłów zostanie ustawiona na 2 lub wyższe.
Konfigurowanie istniejącego własnego środowiska IR za pomocą lokalnego programu PowerShell
Możesz użyć wiersza polecenia, aby skonfigurować istniejące własne środowisko IR lub zarządzać nim. To użycie może szczególnie pomóc zautomatyzować instalację i rejestrację samodzielnie hostowanych węzłów IR.
Dmgcmd.exe znajduje się w instalatorze hostowanym samodzielnie. Zazwyczaj znajduje się w folderze C:\Program Files\Microsoft Integration Runtime\5.0\Shared\. Ta aplikacja obsługuje różne parametry i może być wywoływana za pośrednictwem wiersza polecenia przy użyciu skryptów wsadowych na potrzeby automatyzacji.
Użyj aplikacji w następujący sposób:
dmgcmd ACTION args...
Poniżej przedstawiono szczegółowe informacje o akcjach i argumentach aplikacji:
| AKCJA | argumenty | opis |
|---|---|---|
-rn,-RegisterNewNode |
"<AuthenticationKey>" [""<NodeName>] |
Zarejestruj węzeł własnego środowiska Integration Runtime z określonym kluczem uwierzytelniania i nazwą węzła. |
-era,-EnableRemoteAccess |
"<port>" [""<thumbprint>] |
Włącz dostęp zdalny w bieżącym węźle, aby skonfigurować klaster o wysokiej dostępności. Możesz też włączyć poświadczenia ustawień bezpośrednio względem własnego środowiska IR bez przechodzenia przez obszar roboczy usługi Azure Data Factory lub Azure Synapse. W tym drugim celu należy użyć polecenia cmdlet New-AzDataFactoryV2LinkedServiceEncryptedCredential z maszyny zdalnej w tej samej sieci. |
-erac,-EnableRemoteAccessInContainer |
"<port>" [""<thumbprint>] |
Włącz dostęp zdalny do bieżącego węzła, gdy węzeł działa w kontenerze. |
-dra,-DisableRemoteAccess |
Wyłącz dostęp zdalny do bieżącego węzła. Do skonfigurowania wielu węzłów wymagany jest dostęp zdalny. Polecenie cmdlet New-AzDataFactoryV2LinkedServiceEncryptedCredential programu PowerShell działa nawet wtedy, gdy dostęp zdalny jest wyłączony. To zachowanie działa poprawnie, o ile cmdlet jest wykonywany na tej samej maszynie co samodzielnie hostowany węzeł IR. | |
-k,-Key |
<AuthenticationKey>
|
Zastąp lub zaktualizuj poprzedni klucz uwierzytelniania. Bądź ostrożny z tą czynnością. Twój poprzedni węzeł IR hostowany lokalnie może przejść w tryb offline, jeśli klucz jest dla nowego środowiska Integration Runtime. |
-gbf,-GenerateBackupFile |
"<filePath>" "<password>" |
Wygeneruj plik kopii zapasowej dla bieżącego węzła. Plik kopii zapasowej zawiera klucz węzła i poświadczenia magazynu danych. |
-ibf,-ImportBackupFile |
"<filePath>" "<password>" |
Przywróć węzeł z pliku kopii zapasowej. |
-r,-Restart |
Uruchom ponownie usługę hosta samodzielnie obsługiwanego środowiska Integration Runtime. | |
-s,-Start |
Uruchom własną usługę hosta środowiska Integration Runtime. | |
-t,-Stop |
Zatrzymaj usługę hosta własnego środowiska Integration Runtime. | |
-sus,-StartUpgradeService |
Uruchom usługę uaktualniania własnego środowiska Integration Runtime. | |
-tus,-StopUpgradeService |
Zatrzymaj usługę uaktualniania własnego środowiska Integration Runtime. | |
-tonau,-TurnOnAutoUpdate |
Włącz automatyczną aktualizację własnego środowiska Integration Runtime. To polecenie dotyczy tylko usługi Azure Data Factory w wersji 1. | |
-toffau,-TurnOffAutoUpdate |
Wyłącz automatyczną aktualizację własnego środowiska Integration Runtime. To polecenie dotyczy tylko usługi Azure Data Factory w wersji 1. | |
-ssa,-SwitchServiceAccount |
"<domain\user>" [""<password>] |
Ustaw usługę DIAHostService, aby uruchomić ją jako nowe konto. Użyj pustego hasła "" dla kont systemowych i kont wirtualnych. |
-elma,-EnableLocalMachineAccess |
Włącz dostęp do komputera lokalnego (localhost, prywatny adres IP) w bieżącym węźle własnego środowiska IR. W scenariuszu wysokiej dostępności własnego środowiska IR akcja musi zostać wywołana w każdym węźle własnego środowiska IR. | |
-dlma,-DisableLocalMachineAccess |
Wyłącz dostęp do komputera lokalnego (localhost, prywatny adres IP) na bieżącym samodzielnie hostowanym węźle IR. W scenariuszu wysokiej dostępności własnego środowiska IR akcja musi zostać wywołana w każdym węźle własnego środowiska IR. | |
-DisableLocalFolderPathValidation |
Wyłącz walidację zabezpieczeń, aby umożliwić dostęp do systemu plików komputera lokalnego. | |
-EnableLocalFolderPathValidation |
Włącz walidację zabezpieczeń, aby wyłączyć dostęp do systemu plików komputera lokalnego. | |
-eesp,-EnableExecuteSsisPackage |
Włącz wykonywanie pakietów usług SSIS w węźle własnego środowiska IR. | |
-desp,-DisableExecuteSsisPackage |
Wyłącz wykonywanie pakietów usług SSIS w węźle własnego środowiska IR. | |
-gesp,-GetExecuteSsisPackage |
Pobierz wartość, jeśli opcja ExecuteSsisPackage jest włączona w węźle własnego środowiska IR. Jeśli zwrócona wartość ma wartość true, funkcja ExecuteSSISPackage jest włączona; Jeśli zwracana wartość ma wartość false lub null, pakiet ExecuteSSISPackage jest wyłączony. |
Instalowanie i rejestrowanie własnego środowiska IR z Centrum pobierania Microsoft
Przejdź do strony pobierania środowiska Microsoft Integration Runtime.
Wybierz pozycję Pobierz, wybierz wersję 64-bitową, a następnie wybierz pozycję Dalej. Wersja 32-bitowa nie jest obsługiwana.
Uruchom plik MSI bezpośrednio lub zapisz go na dysku twardym i uruchom go.
W oknie Powitanie wybierz język i wybierz przycisk Dalej.
Zaakceptuj postanowienia licencyjne dotyczące oprogramowania firmy Microsoft i wybierz pozycję Dalej.
Wybierz folder , aby zainstalować własne środowisko Integration Runtime, a następnie wybierz pozycję Dalej.
Na stronie Gotowe do instalacji wybierz opcję Zainstaluj.
Wybierz pozycję Zakończ , aby ukończyć instalację.
Pobierz klucz uwierzytelniania przy użyciu programu PowerShell. Oto przykład programu PowerShell do pobierania klucza uwierzytelniania:
Get-AzDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeNameW oknie Rejestrowanie środowiska Integration Runtime (self-hosted) programu Microsoft Integration Runtime Configuration Manager uruchomionego na maszynie wykonaj następujące czynności:
Wklej klucz uwierzytelniania w obszarze tekstowym.
Opcjonalnie wybierz pozycję Pokaż klucz uwierzytelniania, aby wyświetlić tekst klucza.
Wybierz pozycję Zarejestruj.
Uwaga
Informacje o wersji są dostępne na tej samej stronie pobierania środowiska Microsoft Integration Runtime.
Konto usługi dla autonomicznego środowiska Integration Runtime
Domyślne konto usługi samodzielnie hostowanego środowiska wykonawczego (Integration Runtime) to NT SERVICE\DIAHostService. Możesz go zobaczyć w Usługi —> Usługa Integration Runtime —> Właściwości —> Logowanie.
Upewnij się, że konto ma uprawnienie „Zaloguj się jako usługa”. W przeciwnym razie samodzielnie hostowane środowisko Integration Runtime nie może uruchomić się pomyślnie. Uprawnienie można sprawdzić w obszarze Zasady zabezpieczeń lokalnych —> Ustawienia zabezpieczeń —> Zasady lokalne —> Przypisywanie praw użytkownika —> Logowanie jako usługa
Ikony i powiadomienia obszaru powiadomień
Jeśli przeniesiesz kursor na ikonę lub komunikat w obszarze powiadomień, zobaczysz szczegółowe informacje o stanie własnego środowiska Integration Runtime.
Wysoka dostępność i skalowalność
Możesz skojarzyć własne środowisko Integration Runtime z wieloma maszynami lokalnymi lub maszynami wirtualnymi na platformie Azure. Te maszyny są nazywane węzłami. Z własnym środowiskiem Integration Runtime może być skojarzonych maksymalnie cztery węzły. Korzyści wynikające z posiadania wielu węzłów na maszynach lokalnych, które mają bramę zainstalowaną dla bramy logicznej, to:
- Wyższa dostępność własnego środowiska Integration Runtime, dzięki czemu nie jest to już pojedynczy punkt awarii rozwiązania do obsługi danych big data ani integracja danych w chmurze. Ta dostępność pomaga zapewnić ciągłość korzystania z maksymalnie czterech węzłów.
- Zwiększona wydajność i przepływność podczas przenoszenia danych między magazynami danych lokalnych i w chmurze. Uzyskaj więcej informacji na temat porównań wydajności.
Można skojarzyć wiele węzłów, instalując oprogramowanie do integracji w środowisku własnym z Centrum pobierania. Następnie zarejestruj go, używając jednego z kluczy uwierzytelniania uzyskanych z polecenia cmdlet New-AzDataFactoryV2IntegrationRuntimeKey zgodnie z opisem w samouczku.
Uwaga
Nie musisz tworzyć nowego własnego środowiska Integration Runtime, aby skojarzyć każdy węzeł. Możesz zainstalować własne środowisko Integration Runtime na innej maszynie i zarejestrować je przy użyciu tego samego klucza uwierzytelniania.
Uwaga
Przed dodaniem innego węzła w celu zapewnienia wysokiej dostępności i skalowalności upewnij się, że opcja Dostęp zdalny do intranetu jest włączona w pierwszym węźle. W tym celu wybierz pozycję Microsoft Integration Runtime Configuration Manager>Ustawienia>Dostęp zdalny do intranetu.
Zagadnienia dotyczące skalowania
Skalowanie w poziomie
Gdy użycie procesora jest wysokie, a ilość dostępnej pamięci jest niska w środowisku IR hostowanym samodzielnie, dodaj nowy węzeł, aby ułatwić skalowanie obciążenia między maszynami. Jeśli działania kończą się niepowodzeniem, ponieważ upłynął limit czasu lub węzeł własnego środowiska IR jest w trybie offline, pomaga to w przypadku dodania węzła do bramy. Aby dodać węzeł, wykonaj następujące kroki:
- Pobierz konfigurację SHIR z portalu usługi Azure Data Factory.
- Uruchom Instalatora w węźle, który chcesz dodać do klastra.
- Podczas instalacji wybierz opcję dołączenia do istniejącego środowiska Integration Runtime i podaj klucz uwierzytelniania z istniejącego środowiska SHIR, aby połączyć nowy węzeł z istniejącym klastrem SHIR.
Zwiększanie skali
Gdy procesor i dostępna pamięć RAM nie są dobrze wykorzystywane, ale wykonywanie współbieżnych zadań osiągnie limity węzła, skaluj w górę, zwiększając liczbę współbieżnych zadań, które można uruchomić w węźle. Możesz również chcieć zwiększyć skalę, gdy działania przekraczają limit czasu, ponieważ lokalnie hostowane środowisko IR jest przeciążone. Jak pokazano na poniższej ilustracji, można zwiększyć maksymalną pojemność węzła:
Wymagania dotyczące certyfikatów TLS/SSL
Jeśli chcesz włączyć dostęp zdalny z intranetu przy użyciu certyfikatu TLS/SSL (zaawansowane) w celu zabezpieczenia komunikacji między węzłami środowiska Integration Runtime, możesz wykonać kroki opisane w temacie Włączanie dostępu zdalnego z intranetu przy użyciu certyfikatu TLS/SSL.
Uwaga
Ten certyfikat jest używany:
- Aby zaszyfrować porty na samodzielnie hostowanym węźle IR.
- W przypadku komunikacji między węzłami na potrzeby synchronizacji stanu, która obejmuje synchronizację poświadczeń połączonych usług między węzłami.
- Gdy polecenie cmdlet programu PowerShell jest używane do ustawień poświadczeń usługi połączonej z sieci lokalnej.
Zalecamy użycie tego certyfikatu, jeśli środowisko sieci prywatnej nie jest bezpieczne lub jeśli chcesz zabezpieczyć komunikację między węzłami w sieci prywatnej.
Przenoszenie danych przesyłanych z własnego środowiska IR do innych magazynów danych zawsze odbywa się w ramach zaszyfrowanego kanału, niezależnie od tego, czy ten certyfikat jest ustawiony.
Synchronizacja poświadczeń
Jeśli nie przechowujesz poświadczeń ani wartości wpisów tajnych w usłudze Azure Key Vault, poświadczenia lub wartości wpisów tajnych będą przechowywane na maszynach, na których znajduje się własne środowisko Integration Runtime. Każdy węzeł będzie miał kopię poświadczeń z określoną wersją. Aby wszystkie węzły działały razem, numer wersji powinien być taki sam dla wszystkich węzłów.
Zagadnienia dotyczące serwera proxy
Jeśli środowisko sieciowe firmy używa serwera proxy do uzyskiwania dostępu do Internetu, skonfiguruj własne środowisko Integration Runtime do używania odpowiednich ustawień serwera proxy. Serwer proxy można ustawić w początkowej fazie rejestracji.
Po skonfigurowaniu własne środowisko Integration Runtime używa serwera proxy do łączenia się ze źródłem i miejscem docelowym usługi w chmurze (które używają protokołu HTTP lub HTTPS). Dlatego podczas początkowej konfiguracji należy wybrać pozycję Zmień link .
Dostępne są trzy opcje konfiguracji:
- Nie używaj serwera proxy: własne środowisko Integration Runtime nie używa jawnie żadnego serwera proxy do łączenia się z usługami w chmurze.
- Użyj serwera proxy systemu: własne środowisko Integration Runtime używa ustawienia serwera proxy skonfigurowanego w pliku diahost.exe.config i diawp.exe.config. Jeśli te pliki nie określają konfiguracji serwera proxy, własne środowisko Integration Runtime łączy się bezpośrednio z usługą w chmurze bez przechodzenia przez serwer proxy.
- Użyj niestandardowego serwera proxy: Skonfiguruj ustawienie serwera proxy HTTP, które ma być użyte z własnym środowiskiem uruchomieniowym Integration Runtime, zamiast korzystać z konfiguracji w plikach diahost.exe.config i diawp.exe.config. Wartości adres oraz port są wymagane. Wartości nazwy użytkownika i hasła są opcjonalne w zależności od ustawienia uwierzytelniania serwera proxy. Wszystkie ustawienia są szyfrowane przy użyciu interfejsu DPAPI systemu Windows w własnym środowisku Integration Runtime i przechowywane lokalnie na maszynie.
Usługa hosta środowiska uruchomieniowego Integration Runtime jest automatycznie restartowana po zapisaniu zaktualizowanych ustawień serwera proxy.
Aby wyświetlić lub zaktualizować ustawienia serwera proxy po zarejestrowaniu własnego środowiska Integration Runtime, użyj programu Microsoft Integration Runtime Configuration Manager.
- Otwórz program Microsoft Integration Runtime Configuration Manager.
- Wybierz kartę Ustawienia.
- W obszarze Serwer proxy HTTP wybierz opcję Zmień, aby otworzyć okno dialogowe Ustaw serwer proxy HTTP.
- Wybierz Dalej. Zostanie wyświetlone ostrzeżenie z prośbą o pozwolenie na zapisanie ustawienia serwera proxy i ponowne uruchomienie usługi hosta środowiska Integration Runtime.
Aby wyświetlić i zaktualizować serwer proxy HTTP, możesz użyć narzędzia configuration manager.
Uwaga
Jeśli skonfigurujesz serwer proxy z uwierzytelnianiem NTLM, usługa hosta środowiska Integration Runtime zostanie uruchomiona na koncie domeny. Jeśli później zmienisz hasło dla konta domeny, pamiętaj o zaktualizowaniu ustawień konfiguracji usługi i ponownym uruchomieniu usługi. Ze względu na to wymaganie zalecamy, aby uzyskać dostęp do serwera proxy przy użyciu dedykowanego konta domeny, które nie wymaga częstego aktualizowania hasła.
Konfigurowanie ustawień serwera proxy
Jeśli wybierzesz opcję Użyj serwera proxy systemu dla proxy HTTP, samodzielnie hostowane środowisko uruchomieniowe korzysta z ustawień proxy zawartych w diahost.exe.config i diawp.exe.config. Gdy pliki te nie określają serwera proxy, samodzielnie hostowane środowisko uruchomieniowe łączy się bezpośrednio z usługą w chmurze, pomijając serwer proxy. Poniższa procedura zawiera instrukcje dotyczące aktualizowania pliku diahost.exe.config:
W Eksplorator plików utwórz bezpieczną kopię pliku C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config jako kopię zapasową oryginalnego pliku.
Otwórz Notatnik uruchomiony jako administrator.
W Notatniku otwórz plik tekstowy C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.
Znajdź domyślny tag system.net , jak pokazano w poniższym kodzie:
<system.net> <defaultProxy useDefaultCredentials="true" /> </system.net>Następnie możesz dodać szczegóły serwera proxy, jak pokazano w poniższym przykładzie:
<system.net> <defaultProxy enabled="true"> <proxy bypassonlocal="true" proxyaddress="http://proxy.domain.org:8888/" /> </defaultProxy> </system.net>Tag serwera proxy umożliwia dodatkowe właściwości określania wymaganych ustawień, takich jak
scriptLocation. Aby uzyskać składnię, zobacz element <proxy> (ustawienia sieci).<proxy autoDetect="true|false|unspecified" bypassonlocal="true|false|unspecified" proxyaddress="uriString" scriptLocation="uriString" usesystemdefault="true|false|unspecified "/>Zapisz plik konfiguracji w oryginalnej lokalizacji. Następnie uruchom ponownie usługę hosta własnego środowiska Integration Runtime, która pobiera zmiany.
Aby ponownie uruchomić usługę, użyj apletu usług z Panel sterowania. Lub w programie Integration Runtime Configuration Manager wybierz przycisk Zatrzymaj usługę, a następnie wybierz pozycję Uruchom usługę.
Jeśli usługa nie zostanie uruchomiona, prawdopodobnie dodano niepoprawną składnię tagów XML w edytowanym pliku konfiguracji aplikacji.
Ważne
Nie zapomnij zaktualizować zarówno diahost.exe.config, jak i diawp.exe.config.
Należy również upewnić się, że platforma Microsoft Azure znajduje się na liście dozwolonych twojej firmy. Możesz pobrać listę prawidłowych adresów IP platformy Azure. Zakresy adresów IP dla każdej chmury podzielone według regionów i oznakowanych usług w chmurze są teraz dostępne w witrynie MS Download:
- Publiczny: https://www.microsoft.com/download/details.aspx?id=56519
- Rząd USA: https://www.microsoft.com/download/details.aspx?id=57063
- Niemcy: https://www.microsoft.com/download/details.aspx?id=57064
- Chiny: https://www.microsoft.com/download/details.aspx?id=57062
Konfigurowanie ustawień serwera proxy podczas korzystania z prywatnego punktu końcowego
Jeśli architektura sieci firmy obejmuje korzystanie z prywatnych punktów końcowych i ze względów bezpieczeństwa, a zasady firmy nie zezwalają na bezpośrednie połączenie internetowe z maszyny wirtualnej hostujących własne środowisko Integration Runtime do adresu URL usługi Azure Data Factory, należy zezwolić na obejście adresu URL usługi ADF w celu zapewnienia pełnej łączności. Poniższa procedura zawiera instrukcje dotyczące aktualizowania pliku diahost.exe.config. Należy również powtórzyć te kroki dla pliku diawp.exe.config.
W Eksplorator plików utwórz bezpieczną kopię pliku C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config jako kopię zapasową oryginalnego pliku.
Otwórz Notatnik uruchomiony jako administrator.
W Notatniku otwórz plik C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.
Znajdź domyślny tag system.net , jak pokazano tutaj:
<system.net> <defaultProxy useDefaultCredentials="true" /> </system.net>Następnie możesz dodać szczegóły listy obejść, jak w pokazanym poniżej przykładzie:
<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>
Możliwe objawy problemów związanych z zaporą i serwerem proxy
Jeśli zobaczysz komunikaty o błędach, takie jak poniższe, prawdopodobną przyczyną jest niewłaściwa konfiguracja zapory lub serwera proxy. Taka konfiguracja uniemożliwia środowisku integracji uruchomieniowej hostowanemu samodzielnie nawiązywanie połączenia z potokami usługi Data Factory lub Synapse w celu uwierzytelnienia się. Aby upewnić się, że zapora i serwer proxy są prawidłowo skonfigurowane, zapoznaj się z poprzednią sekcją.
Podczas próby zarejestrowania własnego środowiska Integration Runtime zostanie wyświetlony następujący komunikat o błędzie: "Nie można zarejestrować tego węzła środowiska Integration Runtime! Upewnij się, że klucz uwierzytelniania jest prawidłowy, a usługa hosta integracji jest uruchomiona na tym komputerze.
Po otwarciu programu Integration Runtime Configuration Manager zostanie wyświetlony stan Rozłączone lub Łączenie. Podczas wyświetlania dzienników zdarzeń systemu Windows w obszarze Podgląd zdarzeń>Dzienniki aplikacji i usług>Microsoft Integration Runtime, są wyświetlane komunikaty o błędach podobne do następującego:
Unable to connect to the remote server A component of Integration Runtime has become unresponsive and restarts automatically. Component name: Integration Runtime (self-hosted).
Włączanie dostępu zdalnego z intranetu
Jeśli używasz programu PowerShell do szyfrowania poświadczeń z komputera sieciowego innego niż miejsce, w którym zainstalowano własne środowisko Integration Runtime, możesz włączyć opcję Dostęp zdalny z intranetu. Jeśli uruchomisz program PowerShell w celu zaszyfrowania poświadczeń na maszynie, na której zainstalowano własne środowisko Integration Runtime, nie możesz włączyć dostępu zdalnego z intranetu.
Włącz dostęp zdalny z intranetu przed dodaniem innego węzła w celu zapewnienia wysokiej dostępności i skalowalności.
Po uruchomieniu konfiguracji samodzielnie hostowanego środowiska Integration Runtime w wersji 3.3 lub późniejszej, instalator domyślnie wyłącza dostęp zdalny z intranetu na tej maszynie.
W przypadku korzystania z zapory dostarczonej przez partnera lub inne osoby, można ręcznie otworzyć port 8060 lub port skonfigurowany przez użytkownika. Jeśli masz problem z zaporą podczas konfigurowania własnego środowiska Integration Runtime, użyj następującego polecenia, aby zainstalować własne środowisko Integration Runtime bez konfigurowania zapory:
msiexec /q /i IntegrationRuntime.msi NOFIREWALL=1
Jeśli zdecydujesz się nie otwierać portu 8060 na maszynie własnego środowiska Integration Runtime, użyj mechanizmów innych niż aplikacja Ustawianie poświadczeń w celu skonfigurowania poświadczeń magazynu danych. W programie PowerShell można na przykład użyć polecenia typu cmdlet New-AzDataFactoryV2LinkedServiceEncryptCredential.
Porty i zapory
Należy wziąć pod uwagę dwie zapory:
- Zapora firmowa działająca na centralnym routerze organizacji
- Zapora systemu Windows skonfigurowana jako usługa na komputerze lokalnym, na którym zainstalowano własne środowisko wykonawcze integracji.
Na poziomie zapory firmowej należy skonfigurować następujące domeny i porty wychodzące:
| Nazwy domen | Porty wychodzące | opis |
|---|---|---|
Chmura publiczna: *.servicebus.windows.net Azure Government: *.servicebus.usgovcloudapi.net Chiny: *.servicebus.chinacloudapi.cn |
443 | Wymagane przez własne środowisko Integration Runtime do tworzenia interakcyjnego. Nie jest wymagane, jeśli jest włączone samodzielne tworzenie interakcyjne. |
Chmura publiczna: {datafactory}.{region}.datafactory.azure.netlub *.frontend.clouddatahub.net Azure Government: {datafactory}.{region}.datafactory.azure.us Chiny: {datafactory}.{region}.datafactory.azure.cn |
443 | Wymagane przez samodzielnie hostowane środowisko Integration Runtime do nawiązania połączenia z usługą Data Factory. W przypadku nowo utworzonej usługi Data Factory w chmurze publicznej znajdź w pełni kwalifikowaną nazwę domeny (FQDN) z klucza własnego środowiska Integration Runtime, który jest w formacie {data factory}. {region}.datafactory.azure.net. W przypadku starego Data Factory i dowolnej wersji usługi Azure Synapse Analytics, jeśli nie widzisz nazwy FQDN w kluczu integracji hostowanej samodzielnie, użyj *.frontend.clouddatahub.net zamiast. |
download.microsoft.com |
443 | Wymagane przez własne środowisko Integration Runtime do pobierania aktualizacji. Jeśli wyłączono automatyczną aktualizację, możesz pominąć konfigurowanie tej domeny. |
| Adres URL magazynu kluczy | 443 | Wymagane przez usługę Azure Key Vault w przypadku przechowywania poświadczeń w usłudze Key Vault. |
Na poziomie zapory systemu Windows lub komputera te porty wychodzące są zwykle włączone. Jeśli tak nie jest, możesz skonfigurować domeny i porty na maszynie własnego środowiska Integration Runtime.
Uwaga
Ponieważ obecnie Azure Relay nie obsługuje tagów usługi, musisz używać tagu AzureCloud lub Internet w regułach sieciowej grupy zabezpieczeń w celu komunikacji z Azure Relay. W przypadku komunikacji z obszarami roboczymi Azure Data Factory i Synapse można użyć tagu DataFactoryManagement w konfiguracji reguły grupy zabezpieczeń sieci.
Na podstawie źródła i ujścia może być konieczne zezwolenie na dodatkowe domeny i porty wychodzące w zaporze firmowej lub Zaporze systemu Windows.
| Nazwy domen | Porty wychodzące | opis |
|---|---|---|
*.core.windows.net |
443 | Używane przez samodzielnie hostowane środowisko wykonawcze integracji do nawiązywania połączenia z kontem usługi Azure Storage podczas korzystania z funkcji kopiowania etapowego. |
*.database.windows.net |
1433 | Wymagane tylko w przypadku kopiowania z lub do usługi Azure SQL Database lub Azure Synapse Analytics i opcjonalnie w przeciwnym razie. Funkcja kopiowania etapowego umożliwia kopiowanie danych do usługi SQL Database lub Azure Synapse Analytics bez otwierania portu 1433. |
*.azuredatalakestore.netlogin.microsoftonline.com/<tenant>/oauth2/token |
443 | Wymagane tylko podczas kopiowania z usługi Azure Data Lake Store lub do niej, a w przeciwnym razie opcjonalnie. |
W przypadku niektórych baz danych w chmurze, takich jak Usługi Azure SQL Database i Azure Data Lake, może być konieczne zezwolenie na używanie adresów IP maszyn z własnym środowiskiem Integration Runtime w konfiguracji zapory.
Uwaga
Nie ma prawa instalować zarówno środowiska Integration Runtime, jak i bramy usługi Power BI na tej samej maszynie, ponieważ głównie środowisko Integration Runtime używa portu numer 443, który jest jednym z głównych portów używanych przez bramę usługi Power BI.
Samodzielne interaktywne tworzenie treści
Aby wykonać interaktywne akcje tworzenia, takie jak podgląd danych i testowanie połączenia, własne środowisko Integration Runtime wymaga połączenia z usługą Azure Relay. Jeśli połączenie nie zostanie nawiązane, istnieją dwa możliwe rozwiązania zapewniające nieprzerwane działanie. Pierwszą opcją jest dodanie punktów końcowych usługi Azure Relay do listy dozwolonych zapory sieciowej Uzyskaj adres URL usługi Azure Relay. Alternatywnie możesz włączyć samodzielne interaktywne tworzenie.
Uwaga
Jeśli własne środowisko Integration Runtime nie może nawiązać połączenia z usługą Azure Relay, jego stan zostanie oznaczony jako "ograniczony".
Uwaga
Gdy będzie włączone samodzielne interaktywne tworzenie, cały ruch związany z interaktywnym autorstwem będzie kierowany wyłącznie za pośrednictwem tej funkcji, omijając Azure Relay. Ruch zostanie przekierowany tylko z powrotem do usługi Azure Relay po wybraniu wyłączenia tej funkcji.
Uwaga
Zarówno "Pobierz adres IP", jak i "Wyślij dziennik" nie są obsługiwane, gdy samodzielne interaktywne autorstwo jest włączone.
Uzyskiwanie adresu URL usługi Azure Relay
Jedną z wymaganych domen i portów, które należy umieścić na liście dozwolonych zapory, jest komunikacja z usługą Azure Relay. "Samodzielnie hostowane środowisko uruchomieniowe integracji używa go do interaktywnego tworzenia, na przykład do testowania połączenia, przeglądania listy folderów i listy tabel, pobierania schematu oraz podglądu danych." Jeśli nie chcesz zezwalać na korzystanie z platformy .servicebus.windows.net i chcesz mieć bardziej szczegółowe adresy URL, możesz zobaczyć wszystkie nazwy FQDN wymagane przez własne środowisko Integration Runtime z poziomu portalu usługi.
Uzyskiwanie adresu URL usługi Azure Relay za pośrednictwem interfejsu użytkownika:
Wykonaj te kroki:
Przejdź do portalu usługi i wybierz własne środowisko Integration Runtime.
Na stronie Edytuj wybierz Węzły.
Wybierz Wyświetl adresy URL usługi, aby uzyskać wszystkie FQDN.
Azure Relay URL-e
Te nazwy FQDN można dodać na liście dozwolonych reguł zapory.
Uwaga
Aby uzyskać szczegółowe informacje dotyczące protokołu połączeń usługi Azure Relay, zobacz Protokół połączeń hybrydowych usługi Azure Relay.
Uzyskiwanie adresu URL usługi Azure Relay za pośrednictwem skryptu:
# 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]$synapseResourceGroupName = "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
Kopiowanie danych ze źródła do ujścia
Upewnij się, że reguły zapory są prawidłowo włączone w zaporze firmowej, zaporze systemu Windows na maszynie własnego środowiska Integration Runtime i samym magazynie danych. Włączenie tych reguł pozwala na pomyślne połączenie własnego środowiska Integration Runtime z źródłem i ujściem. Włącz reguły dla każdego magazynu danych, który jest zaangażowany w operację kopiowania.
Aby na przykład skopiować z lokalnego magazynu danych do ujścia usługi SQL Database lub ujścia usługi Azure Synapse Analytics, wykonaj następujące kroki:
- Zezwalaj na wychodzącą komunikację TCP na porcie 1433 zarówno dla zapory systemu Windows, jak i zapory firmowej.
- Skonfiguruj ustawienia zapory dla bazy danych SQL, aby dodać adres IP maszyny samodzielnie hostowanego środowiska integracji do listy dozwolonych adresów IP.
Uwaga
Jeśli zapora nie zezwala na ruch wychodzący przez port 1433, samodzielnie hostowane środowisko Integration Runtime nie może bezpośrednio uzyskać dostępu do bazy danych SQL. W takim przypadku możesz użyć kopii etapowej do usług SQL Database i Azure Synapse Analytics. W tym scenariuszu wymagany jest tylko protokół HTTPS (port 443) dla przenoszenia danych.
Jeśli wszystkie źródła danych, ujścia i samoobsługowe środowisko integracyjne typu Runtime znajdują się w środowisku lokalnym, skopiowane dane nie zostaną przeniesione do chmury i pozostaną w środowisku lokalnym.
Przechowywanie poświadczeń
Istnieją dwa sposoby przechowywania poświadczeń podczas korzystania z własnego środowiska Integration Runtime:
Korzystanie z usługi Azure Key Vault (zalecane) — własne środowisko Integration Runtime może bezpośrednio uzyskać poświadczenia z usługi Azure Key Vault, co pozwala uniknąć niektórych potencjalnych problemów z zabezpieczeniami lub problemów z synchronizacją poświadczeń między własnymi węzłami środowiska Integration Runtime.
Przechowywanie poświadczeń lokalnie — poświadczenia zostaną przesłane na maszynę, na której zainstalowano samodzielnie hostowane środowisko Integration Runtime i zostaną zaszyfrowane.
Uwaga
Jeśli wolisz przechowywać poświadczenia lokalnie, musisz umieścić domenę na potrzeby interaktywnego tworzenia na liście dozwolonych zapory i otworzyć port. Ten kanał umożliwia również własne środowisko Integration Runtime uzyskanie poświadczeń. Aby uzyskać informacje o domenie i portach wymaganych do tworzenia interakcyjnego, zapoznaj się z tematem Porty i zapory
Jeśli przywracasz własne środowisko Integration Runtime po awarii, możesz odzyskać poświadczenia z kopii zapasowej, którą zapisałeś, lub edytować połączoną usługę, aby ponownie zastosować poświadczenia w własnym środowisku Integration Runtime. W przeciwnym razie potok korzystający z własnego środowiska Integration Runtime nie będzie działać ze względu na brak poświadczeń.
Najlepsze rozwiązania dotyczące instalacji
Możesz zainstalować własne środowisko Integration Runtime, pobierając pakiet instalacyjny tożsamości zarządzanej z Centrum pobierania Microsoft. Zobacz artykuł Przenoszenie danych między środowiskiem lokalnym i chmurą , aby uzyskać instrukcje krok po kroku.
- Skonfiguruj plan zasilania na maszynie hosta dla własnego środowiska Integration Runtime, aby maszyna nie była hibernacji. Jeśli hibernacji maszyny hosta własne środowisko Integration Runtime przejdzie w tryb offline.
- Regularnie twórz kopię zapasową poświadczeń związanych ze środowiskiem uruchomieniowym z samodzielnym hostingiem.
- Aby zautomatyzować operacje konfiguracji własnego środowiska IR, zobacz Konfigurowanie istniejącego własnego środowiska IR za pomocą programu PowerShell.
- Zainstaluj własne środowisko Integration Runtime na dedykowanych komputerach, aby uzyskać lepszą izolację zasobów i wydajność.
Ważne uwagi
Podczas instalowania własnego środowiska Integration Runtime należy wziąć pod uwagę następujące kwestie
- Zamknij źródło danych, ale niekoniecznie na tej samej maszynie
- Nie instaluj go na tej samej maszynie co brama usługi Power BI
- Tylko system Windows Server (serwery szyfrowania zgodne ze standardem FIPS mogą powodować niepowodzenie zadań)
- Udostępnianie między wieloma źródłami danych
- Dzielenie danych w wielu fabrykach danych
Powiązana zawartość
Aby uzyskać instrukcje krok po kroku, zobacz Samouczek: kopiowanie danych lokalnych do chmury.