Tworzenie i konfigurowanie własnego środowiska Integration Runtime
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. Aby uzyskać szczegółowe informacje na temat środowiska IR, zobacz Omówienie środowiska Integration Runtime.
Własne środowisko Integration Runtime może uruchamiać działania kopiowania pomiędzy magazynem danych w chmurze a magazynem danych w sieci prywatnej. Może również wysyłać działania przekształcania do zasobów obliczeniowych w sieci prywatnej lub w sieci wirtualnej platformy Azure. Instalacja własnego środowiska Integration Runtime musi się odbyć na maszynie lokalnej lub na maszynie wirtualnej w sieci prywatnej.
W tym artykule opisano sposób tworzenia i konfigurowania własnego środowiska IR.
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 własnego środowiska Integration Runtime na maszynie, która różni się od tego, który hostuje lokalne źródło danych. Gdy własne środowisko Integration Runtime i źródło danych znajdują się na różnych maszynach, własne środowisko Integration Runtime nie konkuruje ze źródłem danych dla zasobów.
- 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, nawet jeśli magazyn danych znajduje się w chmurze na maszynie wirtualnej IaaS (Infrastruktura jako usługa platformy Azure).
- 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 własne ś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 połączoną usługę dla lokalnego magazynu danych, określając wystąpienie własnego środowiska Integration Runtime, którego 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 niewidoczna dla dewelopera danych i jest obsługiwana przez własne ś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 w własnym środowisku Integration Runtime. Własne środowisko Integration Runtime uruchamia zadanie po sondowania 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
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 hibernacji maszyny hosta własne środowisko Integration Runtime 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 uzyskać więcej informacji 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ń języka Java zgodnie z opisem 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 własne środowisko Integration Runtime przy użyciu klucza. Oto przykład programu PowerShell:
Get-AzDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName
Uwaga
Uruchom polecenie programu PowerShell w usłudze Azure Government, zobacz Nawiązywanie połączenia z platformą Azure Government przy użyciu programu PowerShell.
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.
Wybierz pozycję Środowiska Integration Runtime w okienku po lewej stronie, a następnie wybierz pozycję +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ę środowiska IR i wybierz pozycję 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 środowisko Integration Runtime (Self-hosted) na lokalną maszynę z systemem Windows. Uruchom instalatora.
Na stronie Rejestrowanie środowiska Integration Runtime (self-hosted) wklej zapisany wcześniej klucz i wybierz pozycję Zarejestruj.
Na stronie Nowy węzeł Integration Runtime (self-hosted) 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ę węzłów własnego środowiska 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 | args | 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 jest prawdziwe, o ile polecenie cmdlet jest wykonywane na tej samej maszynie co węzeł własnego środowiska IR. | |
-k ,-Key |
"<AuthenticationKey> " |
Zastąp lub zaktualizuj poprzedni klucz uwierzytelniania. Zachowaj ostrożność przy użyciu tej akcji. Poprzedni węzeł własnego środowiska IR może przejść w tryb offline, jeśli klucz jest nowym środowiskiem 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 własnego ś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 wartość DIAHostService, aby uruchomić 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) 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. | |
-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 $selfHostedIntegrationRuntimeName
W 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 własnego środowiska Integration Runtime
Domyślne konto usługi własnego środowiska Integration Runtime to NT SERVICE\DIAHostService. Można go zobaczyć w obszarze 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 własne ś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 własne oprogramowanie Integration Runtime z Centrum pobierania. Następnie zarejestruj go przy użyciu 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.
Skalowanie w górę
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ć skalować w górę, gdy przekroczono limit czasu działań, ponieważ własne ś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 w węźle własnego środowiska 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 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 do użycia dla własnego środowiska Integration Runtime, zamiast używać konfiguracji w pliku diahost.exe.config i diawp.exe.config. Wymagane są wartości adresów i portów . 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 Integration Runtime jest uruchamiana automatycznie po zapisaniu zaktualizowanych ustawień serwera proxy.
Jeśli chcesz wyświetlić lub zaktualizować ustawienia serwera proxy po zarejestrowaniu własnego środowiska Integration Runtime Integration Runtime Configuration Manager.
- Otwórz program Microsoft Integration Runtime Configuration Manager.
- Wybierz kartę Ustawienia.
- W obszarze Serwer proxy HTTP wybierz link Zmień , aby otworzyć okno dialogowe Ustawianie serwera 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
W przypadku wybrania opcji Użyj serwera proxy systemu dla serwera proxy HTTP środowisko Integration Runtime self-hosted używa ustawień serwera proxy w pliku diahost.exe.config i diawp.exe.config. Gdy te pliki nie określają serwera proxy, własne środowisko Integration Runtime łączy się bezpośrednio z usługą w chmurze bez przechodzenia przez 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 <proxy> , element (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
- US Gov: 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 architure 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 pokazano w poniższym 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 własnemu środowisku Integration Runtime łączenie się 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 usługi 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ń> Aplikacja i dzienniki usług Środowiska>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 własnego środowiska Integration Runtime setup w wersji 3.3 lub nowszej instalator własnego środowiska Integration Runtime domyślnie wyłącza dostęp zdalny z intranetu na maszynie własnego środowiska Integration Runtime.
W przypadku korzystania z zapory od partnera lub innych osób 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. Można na przykład użyć polecenia cmdlet New-AzDataFactoryV2LinkedServiceEncryptCredential programu PowerShell.
Porty i zapory
Należy wziąć pod uwagę dwie zapory:
- Zapora firmowa działająca na centralnym routerze organizacji
- Zapora systemu Windows skonfigurowana jako demon na komputerze lokalnym, na którym zainstalowano własne środowisko Integration Runtime
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.net lub *.frontend.clouddatahub.net Azure Government: {datafactory}.{region}.datafactory.azure.us Chiny: {datafactory}.{region}.datafactory.azure.cn |
443 | Wymagane przez własne ś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 starej fabryki danych i dowolnej wersji usługi Azure Synapse Analytics, jeśli nie widzisz nazwy FQDN w kluczu integracji hostowanej samodzielnie, użyj *.frontend.clouddatahub.net. |
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 usługa Azure Relay nie obsługuje tagu usługi, musisz użyć tagu usługi AzureCloud lub Internetu w regułach sieciowej grupy zabezpieczeń na potrzeby komunikacji z usługą Azure Relay. W przypadku komunikacji z obszarami roboczymi usług Azure Data Factory i Synapse można użyć tagu usługi DataFactoryManagement w konfiguracji reguły sieciowej grupy zabezpieczeń.
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 własne środowisko Integration Runtime 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 opcjonalnej w przeciwnym razie. Funkcja kopiowania etapowego umożliwia kopiowanie danych do usługi SQL Database lub Azure Synapse Analytics bez otwierania portu 1433. |
*.azuredatalakestore.net login.microsoftonline.com/<tenant>/oauth2/token |
443 | Wymagane tylko w przypadku kopiowania z usługi Azure Data Lake Store lub do usługi Azure Data Lake Store i opcjonalnej w przeciwnym razie. |
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 również przez bramę usługi Power BI.
Samodzielne tworzenie interakcyjne (wersja zapoznawcza)
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 Uzyskiwanie adresu 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
Chociaż jest włączone samodzielne tworzenie interakcyjne, cały ruch interaktywny do tworzenia będzie kierowany wyłącznie za pośrednictwem tej funkcji, pomijając usługę 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" i "Wyślij dziennik" nie są obsługiwane, gdy jest włączone samodzielne interaktywne tworzenie.
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. Własne środowisko Integration Runtime używa go do tworzenia interakcyjnego, takiego jak połączenie testowe, przeglądanie listy folderów i listy tabel, pobieranie schematu i danych podglądu. 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 pozycję Węzły.
Wybierz pozycję Wyświetl adresy URL usługi, aby pobrać wszystkie nazwy FQDN.
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]$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 $synapseRresourceGroupName `
--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 usługi SQL Database, aby dodać adres IP maszyny środowiska Integration Runtime do listy dozwolonych adresów IP.
Uwaga
Jeśli zapora nie zezwala na ruch wychodzący na porcie 1433, własne ś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 i ujścia i własnego środowiska Integration Runtime znajdują się w środowisku lokalnym, skopiowane dane nie zostaną przeniesione do chmury, ale pozostaną ściśle w środowisku lokalnym.
Magazyn poświadczeń
Istnieją dwa sposoby przechowywania poświadczeń podczas korzystania z własnego środowiska Integration Runtime:
- Użyj usługi Azure Key Vault.
Jest to zalecany sposób przechowywania poświadczeń na platformie Azure. 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. 2. Przechowuj poświadczenia lokalnie.
Poświadczenia będą wypychane na maszynę własnego środowiska Integration Runtime i będą szyfrowane. Gdy własne środowisko Integration Runtime zostanie odzyskane po awarii, możesz odzyskać poświadczenia z kopii zapasowej przed lub edytować połączoną usługę i umożliwić wypchnięcie poświadczeń do własnego środowiska Integration Runtime. W przeciwnym razie potok nie działa z powodu braku poświadczeń podczas uruchamiania za pośrednictwem własnego środowiska Integration Runtime.
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ł jest również przeznaczony dla własnego środowiska Integration Runtime w celu uzyskania poświadczeń. Aby uzyskać informacje o domenie i porcie wymaganym do interaktywnego tworzenia, zapoznaj się z tematem Porty i zapory
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 kopię zapasową poświadczeń skojarzonych z własnym środowiskiem Integration Runtime.
- Aby zautomatyzować operacje konfiguracji własnego środowiska IR, zobacz Konfigurowanie istniejącego własnego środowiska IR za pomocą programu PowerShell.
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 w wielu źródłach danych
- Udostępnianie w wielu fabrykach danych
Powiązana zawartość
Aby uzyskać instrukcje krok po kroku, zobacz Samouczek: kopiowanie danych lokalnych do chmury.