Zarządzanie klastrami

W tym artykule opisano sposób zarządzania klastrami usługi Azure Databricks, w tym wyświetlaniem, edytowaniem, uruchamianiem, kończeniem, usuwaniem, kontrolowaniem dostępu oraz monitorowaniem wydajności i dzienników.

Wyświetlanie klastrów

Aby wyświetlić klastry w obszarze roboczym, kliknij pozycję Obliczenia na pasku bocznym.

Po lewej stronie znajdują się dwie kolumny wskazujące, czy klaster został przypięty i stan klastra. Zatrzymaj wskaźnik myszy na stanie, aby uzyskać więcej informacji.

Przypinanie klastra

30 dni po zakończeniu działania klastra zostanie on trwale usunięty. Aby zachować konfigurację klastra ogólnego przeznaczenia po zakończeniu działania klastra przez ponad 30 dni, administrator może przypiąć klaster. Maksymalna liczba klastrów, które można przypiąć, wynosi 100.

Administracja można przypiąć klaster z listy klastra lub strony szczegółów klastra, klikając ikonę pinezki.

Możesz również wywołać punkt końcowy interfejsu API klastrów, aby programowo przypiąć klaster.

Wyświetlanie konfiguracji klastra jako pliku JSON

Czasami pomocne może być wyświetlenie konfiguracji klastra w formacie JSON. Jest to szczególnie przydatne, gdy chcesz utworzyć podobne klastry przy użyciu interfejsu API klastrów. Po wyświetleniu istniejącego klastra przejdź do karty Konfiguracja , kliknij pozycję JSON w prawym górnym rogu karty, skopiuj kod JSON i wklej go do wywołania interfejsu API. Widok JSON jest tylko do odczytu.

Edytowanie klastra

Konfigurację klastra można edytować z poziomu interfejsu użytkownika szczegółów klastra. Możesz również wywołać punkt końcowy interfejsu API klastrów, aby programowo edytować klaster.

Uwaga

• Notesy i zadania dołączone do klastra pozostają dołączone po edycji.
• Biblioteki zainstalowane w klastrze pozostają zainstalowane po edycji.
• Jeśli edytujesz dowolny atrybut uruchomionego klastra (z wyjątkiem rozmiaru klastra i uprawnień), musisz go ponownie uruchomić. Może to zakłócić użytkowników, którzy obecnie korzystają z klastra.
• Można edytować tylko uruchomione lub zakończone klastry. Można jednak zaktualizować uprawnienia dla klastrów, które nie znajdują się w tych stanach, na stronie szczegółów klastra.

Klonowanie klastra

Aby sklonować istniejący klaster, wybierz pozycję Klonuj z menu kebab klastra (znane również jako menu z trzema kropkami).

Po wybraniu opcji klonowania interfejs użytkownika tworzenia klastra zostanie wstępnie wypełniony konfiguracją klastra. Następujące atrybuty nie są uwzględniane w klonie:

• Uprawnienia klastra
• Zainstalowane biblioteki
• Dołączone notesy

Kontrolowanie dostępu do klastrów

Kontrola dostępu do klastra na stronie ustawień administratora umożliwia administratorom obszarów roboczych zapewnienie szczegółowego dostępu do klastra innym użytkownikom. Istnieją dwa typy kontroli dostępu do klastra:

• Uprawnienie do tworzenia klastra: administratorzy obszaru roboczego mogą wybrać, którzy użytkownicy mogą tworzyć klastry.
• Uprawnienia na poziomie klastra: użytkownik, który ma uprawnienie Może zarządzać klastrem, może skonfigurować, czy inni użytkownicy mogą dołączać, uruchamiać ponownie, zmieniać rozmiar i zarządzać tym klastrem.

Aby edytować uprawnienia dla klastra, wybierz pozycję Edytuj uprawnienia z menu kebab tego klastra .

Aby uzyskać więcej informacji na temat kontroli dostępu do klastra i uprawnień na poziomie klastra, zobacz Kontrola dostępu do klastra.

Kończenie klastra

Aby zapisać zasoby klastra, możesz zakończyć działanie klastra. Konfiguracja zakończonego klastra jest przechowywana w taki sposób, aby można było użyć jej ponownie (lub w przypadku zadań automatycznie uruchamianych) w późniejszym czasie. Klaster można ręcznie przerwać lub skonfigurować klaster do automatycznego zakończenia po określonym okresie braku aktywności. Gdy liczba zakończonych klastrów przekroczy 150, najstarsze klastry zostaną usunięte.

Jeśli klaster nie zostanie przypięty lub uruchomiony ponownie, zostanie on automatycznie i trwale usunięty 30 dni po zakończeniu.

Zakończone klastry są wyświetlane na liście klastrów z szarym okręgiem po lewej stronie nazwy klastra.

Uwaga

Po uruchomieniu zadania w nowym klastrze zadań (co jest zwykle zalecane), klaster kończy działanie i jest niedostępny do ponownego uruchomienia po zakończeniu zadania. Z drugiej strony, jeśli planujesz uruchomienie zadania w istniejącym klastrze ogólnego przeznaczenia, który został zakończony, ten klaster zostanie automatycznie uruchomiony.

Ważne

Jeśli używasz obszaru roboczego w wersji próbnej Premium, wszystkie uruchomione klastry zostaną zakończone:

• Podczas uaktualniania obszaru roboczego do pełnej wersji Premium.
• Jeśli obszar roboczy nie zostanie uaktualniony, a wersja próbna wygaśnie.

Ręczne kończenie

Klaster można ręcznie zakończyć z listy klastrów (klikając kwadrat w wierszu klastra) lub stronę szczegółów klastra (klikając pozycję Zakończ).

Automatyczne zakończenie

Możesz również ustawić automatyczne zakończenie dla klastra. Podczas tworzenia klastra można określić okres braku aktywności w minutach, po którym klaster ma zostać zakończony.

Jeśli różnica między bieżącym czasem a ostatnim uruchomieniem polecenia w klastrze przekracza określony okres braku aktywności, usługa Azure Databricks automatycznie zakończy działanie tego klastra.

Klaster jest uznawany za nieaktywny, gdy wszystkie polecenia w klastrze, w tym zadania platformy Spark, przesyłania strumieniowego ze strukturą i wywołania JDBC, zakończyły wykonywanie.

Ostrzeżenie

• Klastry nie zgłaszają aktywności wynikającej z użycia D Strumienie. Oznacza to, że klaster automatycznego kończenie może zostać zakończony, gdy jest uruchomiony D Strumienie. Wyłącz automatyczne kończenie działania klastrów z systemem D Strumienie lub rozważ użycie przesyłania strumieniowego ze strukturą.
• Funkcja automatycznego kończenia monitoruje tylko zadania platformy Spark, a nie zdefiniowane przez użytkownika procesy lokalne. W związku z tym, jeśli wszystkie zadania platformy Spark zostały ukończone, klaster może zostać przerwany, nawet jeśli lokalne procesy są uruchomione.
• Klastry bezczynne nadal gromadzą opłaty za użycie jednostek DBU i wystąpień w chmurze w okresie braku aktywności przed zakończeniem.

Konfigurowanie automatycznego kończenia

Automatyczne kończenie można skonfigurować w interfejsie użytkownika tworzenia klastra. Upewnij się, że pole jest zaznaczone i wprowadź liczbę minut w ustawieniu Zakończ po ___ minutach braku aktywności .

Możesz zrezygnować z automatycznego kończenia, usuwając zaznaczenie pola wyboru Automatyczne kończenie lub określając okres 0braku aktywności .

Uwaga

Automatyczne kończenie jest najlepiej obsługiwane w najnowszych wersjach platformy Spark. Starsze wersje platformy Spark mają znane ograniczenia, które mogą powodować niedokładne raportowanie aktywności klastra. Na przykład klastry z uruchomionymi poleceniami JDBC, R lub streamingiem mogą zgłaszać nieaktualny czas działania, który prowadzi do przedwczesnego zakończenia klastra. Przeprowadź uaktualnienie do najnowszej wersji platformy Spark, aby skorzystać z poprawek błędów i ulepszeń automatycznego kończenia.

Nieoczekiwane zakończenie

Czasami klaster jest nieoczekiwanie przerywany, a nie w wyniku ręcznego zakończenia lub skonfigurowanego automatycznego kończenia.

Aby uzyskać listę przyczyn zakończenia i kroków korygowania, zobacz bazę wiedzy.

Usuwanie klastra

Usunięcie klastra kończy działanie klastra i usuwa jego konfigurację. Aby usunąć klaster, wybierz pozycję Usuń z menu klastra.

Ostrzeżenie

Nie można cofnąć tej akcji.

Aby usunąć przypięty klaster, należy najpierw odpiąć go od administratora.

Możesz również wywołać punkt końcowy interfejsu API klastrów, aby programowo usunąć klaster.

Ponowne uruchamianie klastra

Klaster można ponownie uruchomić z listy klastra, strony szczegółów klastra lub notesu. Możesz również wywołać punkt końcowy interfejsu API klastrów, aby programowo uruchomić klaster.

Usługa Azure Databricks identyfikuje klaster przy użyciu jego unikatowego identyfikatora klastra. Po uruchomieniu zakończonego klastra usługa Databricks ponownie tworzy klaster o tym samym identyfikatorze, automatycznie instaluje wszystkie biblioteki i ponownie dołącza notesy.

Uwaga

Jeśli używasz obszaru roboczego w wersji próbnej, a wersja próbna wygasła, nie będzie można uruchomić klastra.

Uruchom ponownie klaster, aby zaktualizować go przy użyciu najnowszych obrazów

Po ponownym uruchomieniu klastra pobiera on najnowsze obrazy dla kontenerów zasobów obliczeniowych i hostów maszyn wirtualnych. Ważne jest, aby zaplanować regularne ponowne uruchomienia dla długotrwałych klastrów, takich jak te używane do przetwarzania danych przesyłanych strumieniowo.

Twoim zadaniem jest regularne ponowne uruchamianie wszystkich zasobów obliczeniowych w celu zapewnienia aktualności obrazu przy użyciu najnowszej wersji obrazu.

Ważne

Jeśli włączysz profil zabezpieczeń zgodności dla konta lub obszaru roboczego, długotrwałe klastry zostaną automatycznie uruchomione ponownie po upływie 25 dni. Usługa Databricks zaleca ręczne ponowne uruchamianie klastrów przez administratorów obszarów roboczych podczas zaplanowanego okna obsługi. Zmniejsza to ryzyko automatycznego ponownego uruchamiania zakłócającego zaplanowane zadanie.

Przykład notesu: znajdowanie długotrwałych klastrów

Jeśli jesteś administratorem obszaru roboczego, możesz uruchomić skrypt określający, jak długo działa każdy z klastrów, i opcjonalnie uruchom je ponownie, jeśli są starsze niż określona liczba dni. Usługa Azure Databricks udostępnia ten skrypt jako notes.

Pierwsze wiersze skryptu definiują parametry konfiguracji:

• min_age_output: maksymalna liczba dni, przez jaką klaster może działać. Wartość domyślna to 1.
• perform_restart: Jeśli Trueskrypt uruchamia ponownie klastry z wiekiem większym niż liczba dni określonych przez min_age_output. Wartość domyślna to False, która identyfikuje długotrwałe klastry, ale nie uruchamia ich ponownie.
• secret_configuration: Zastąp REPLACE_WITH_SCOPE wartości i REPLACE_WITH_KEY zakresem wpisu tajnego i nazwą klucza. Aby uzyskać więcej informacji na temat konfigurowania wpisów tajnych, zobacz notes.

Ostrzeżenie

Jeśli ustawisz wartość perform_restartTrue, skrypt automatycznie ponownie uruchomi kwalifikujące się klastry, co może spowodować niepowodzenie aktywnych zadań i zresetować otwarte notesy. Aby zmniejszyć ryzyko zakłócania zadań krytycznych dla działania firmy obszaru roboczego, zaplanuj zaplanowane okno obsługi i pamiętaj, aby powiadomić użytkowników obszaru roboczego.

Identyfikowanie i opcjonalne ponowne uruchamianie długotrwałego notesu klastrów

Pobierz notes

Automatyczne uruchamianie klastra dla zadań i zapytań JDBC/ODBC

Po zaplanowaniu uruchomienia zadania przypisanego do zakończonego klastra lub nawiązaniu połączenia z klastrem zakończonym z interfejsu JDBC/ODBC klaster zostanie automatycznie uruchomiony ponownie. Zobacz Tworzenie zadania i nawiązywanie połączenia JDBC.

Automatyczne uruchamianie klastra umożliwia skonfigurowanie klastrów do automatycznego kończenia bez konieczności ręcznego uruchamiania klastrów w celu ponownego uruchomienia klastrów dla zaplanowanych zadań. Ponadto można zaplanować inicjowanie klastra, planując uruchomienie zadania w zakończonym klastrze.

Przed automatycznym ponownym uruchomieniem klastra sprawdzane są uprawnienia kontroli dostępu do klastra i zadania .

Uwaga

Jeśli klaster został utworzony na platformie Azure Databricks w wersji 2.70 lub starszej, nie ma automatycznego startu: zadania zaplanowane do uruchomienia w zakończonych klastrach zakończą się niepowodzeniem.

Wyświetlanie informacji o klastrze w interfejsie użytkownika platformy Apache Spark

Szczegółowe informacje o zadaniach platformy Spark można wyświetlić, wybierając kartę Interfejs użytkownika platformy Spark na stronie szczegółów klastra.

W przypadku ponownego uruchomienia zakończonego klastra interfejs użytkownika platformy Spark wyświetla informacje dotyczące ponownie uruchomionego klastra, a nie informacje historyczne dotyczące zakończonego klastra.

Wyświetlanie dzienników klastrów

Usługa Azure Databricks udostępnia trzy rodzaje rejestrowania działań związanych z klastrem:

• Dzienniki zdarzeń klastra, które przechwytują zdarzenia cyklu życia klastra, takie jak tworzenie, kończenie działania i edytowanie konfiguracji.
• Sterownik platformy Apache Spark i dziennik procesów roboczych, których można użyć do debugowania.
• Dzienniki skryptów inicjowania klastra, które są przydatne podczas debugowania skryptów inicjowania.

W tej sekcji omówiono dzienniki zdarzeń klastra oraz dzienniki sterowników i procesów roboczych. Aby uzyskać szczegółowe informacje na temat dzienników skryptów inicjowania, zobacz Rejestrowanie skryptów init.

Dzienniki zdarzeń klastra

Dziennik zdarzeń klastra wyświetla ważne zdarzenia cyklu życia klastra, które są wyzwalane ręcznie przez akcje użytkownika lub automatycznie przez usługę Azure Databricks. Takie zdarzenia mają wpływ na działanie klastra jako całości i zadań uruchamianych w klastrze.

Aby uzyskać informacje o obsługiwanych typach zdarzeń, zobacz strukturę danych interfejsu API klastrów.

Zdarzenia są przechowywane przez 60 dni, co jest porównywalne z innymi okresami przechowywania danych w usłudze Azure Databricks.

Wyświetlanie dziennika zdarzeń klastra

Aby wyświetlić dziennik zdarzeń klastra, wybierz kartę Dziennik zdarzeń na stronach szczegółów klastra.

Aby uzyskać więcej informacji na temat zdarzenia, kliknij jego wiersz w dzienniku, a następnie kliknij kartę JSON , aby uzyskać szczegółowe informacje.

Dzienniki sterownika klastra i procesu roboczego

Instrukcje drukowania bezpośredniego i rejestrowania z notesów, zadań i bibliotek trafiają do dzienników sterowników platformy Spark. Dostęp do tych plików dziennika można uzyskać na karcie Dzienniki sterowników na stronie szczegółów klastra. Kliknij nazwę pliku dziennika, aby go pobrać.

Dzienniki te zawierają trzy rodzaje danych wyjściowych:

• Wyjście standardowe
• Błąd standardowy
• Dzienniki log4j

Aby wyświetlić dzienniki procesów roboczych platformy Spark, użyj karty Interfejs użytkownika platformy Spark. Możesz również skonfigurować lokalizację dostarczania dziennika dla klastra. Dzienniki procesu roboczego i klastra są dostarczane do określonej lokalizacji.

Monitorowanie wydajności

Aby ułatwić monitorowanie wydajności klastrów usługi Azure Databricks, usługa Azure Databricks zapewnia dostęp do metryk ze strony szczegółów klastra. W przypadku środowiska Databricks Runtime 12.2 lub starszego usługa Azure Databricks zapewnia dostęp do metryk Ganglia . W przypadku środowiska Databricks Runtime w wersji 13.0 lub nowszej metryki klastra są udostępniane przez usługę Azure Databricks.

Ponadto można skonfigurować klaster usługi Azure Databricks do wysyłania metryk do obszaru roboczego usługi Log Analytics w usłudze Azure Monitor, czyli platformie monitorowania dla platformy Azure.

Możesz również zainstalować agentów usługi Datadog w węzłach klastra, aby wysyłać metryki usługi Datadog do konta usługi Datadog.

Metryki klastra

Metryki klastrów to domyślne narzędzie do monitorowania dla środowiska Databricks Runtime 13.0 lub nowszego. Aby uzyskać dostęp do interfejsu użytkownika metryk klastra, przejdź do karty Metryki na stronie szczegółów klastra.

Metryki historyczne można wyświetlić, wybierając zakres czasu przy użyciu filtru selektora dat. Metryki są zbierane co minutę. Możesz również pobrać najnowsze metryki, klikając przycisk Odśwież . Aby uzyskać więcej informacji, zobacz Wyświetlanie metryk klastra na żywo i metryk historycznych.

Metryki Ganglia

Uwaga

Metryki Ganglia są dostępne tylko dla środowiska Databricks Runtime 12.2 lub starszego.

Aby uzyskać dostęp do interfejsu użytkownika Ganglia, przejdź do karty Metryki na stronie szczegółów klastra. Metryki procesora CPU są dostępne w interfejsie użytkownika ganglia dla wszystkich środowisk uruchomieniowych usługi Databricks. Metryki procesora GPU są dostępne dla klastrów z obsługą procesora GPU.

Aby wyświetlić metryki na żywo, kliknij link Ganglia UI .

Aby wyświetlić metryki historyczne, kliknij plik migawki. Migawka zawiera zagregowane metryki dla godziny poprzedzającej wybrany czas.

Uwaga

Platforma Ganglia nie jest obsługiwana w przypadku kontenerów platformy Docker. Jeśli używasz kontenera platformy Docker z klastrem, metryki Ganglia nie będą dostępne.

Konfigurowanie kolekcji metryk Ganglia

Domyślnie usługa Azure Databricks zbiera metryki Ganglia co 15 minut. Aby skonfigurować okres zbierania, ustaw DATABRICKS_GANGLIA_SNAPSHOT_PERIOD_MINUTES zmienną środowiskową przy użyciu skryptu init lub w polu w spark_env_vars interfejsie API tworzenia nowego klastra.

Azure Monitor

Klaster usługi Azure Databricks można skonfigurować tak, aby wysyłał metryki do obszaru roboczego usługi Log Analytics w usłudze Azure Monitor— platformie monitorowania platformy Azure. Aby uzyskać pełne instrukcje, zobacz Monitorowanie w usłudze Azure Databricks.

Uwaga

Jeśli wdrożono obszar roboczy usługi Azure Databricks we własnej sieci wirtualnej i skonfigurowano sieciowe grupy zabezpieczeń w celu odmowy całego ruchu wychodzącego, który nie jest wymagany przez usługę Azure Databricks, musisz skonfigurować dodatkową regułę ruchu wychodzącego dla tagu usługi "AzureMonitor".

Przykład notesu: metryki usługi Datadog

Agenci usługi Datadog można zainstalować w węzłach klastra, aby wysyłać metryki usługi Datadog do konta usługi Datadog. W poniższym notesie pokazano, jak zainstalować agenta usługi Datadog w klastrze przy użyciu skryptu inicjowania o zakresie klastra.

Aby zainstalować agenta usługi Datadog we wszystkich klastrach, zarządzaj skryptem inicjowania o zakresie klastra przy użyciu zasad klastra.

Instalowanie notesu skryptu init agenta usługi Datadog

Pobierz notes

Likwiduj wystąpienia typu spot

Ponieważ wystąpienia typu spot mogą obniżyć koszty, tworzenie klastrów przy użyciu wystąpień typu spot, a nie wystąpień na żądanie, jest typowym sposobem uruchamiania zadań. Jednak wystąpienia typu spot mogą zostać wywłaszczone przez mechanizmy planowania dostawców usług w chmurze. Wywłaszczanie wystąpień typu spot może powodować problemy z uruchomionymi zadaniami, w tym:

• Błędy pobierania shuffle
• Utrata danych w przypadku mieszania
• Utrata danych RDD
• Niepowodzenia zadań

Możesz włączyć likwidowanie, aby rozwiązać te problemy. Likwidowanie korzysta z powiadomienia, które dostawca usług w chmurze zwykle wysyła przed zlikwidowaniem wystąpienia typu spot. Gdy wystąpienie typu spot zawierające funkcję wykonawcza otrzymuje powiadomienie o wywłaszeniu, proces likwidowania podejmie próbę migracji danych mieszania i RDD do funkcji wykonawczej w dobrej kondycji. Czas trwania przed ostatecznym wywłaszczeniem wynosi zazwyczaj od 30 sekund do 2 minut, w zależności od dostawcy usług w chmurze.

Usługa Databricks zaleca włączenie migracji danych w przypadku włączenia likwidowania. Ogólnie rzecz biorąc, możliwość wystąpienia błędów zmniejsza się w miarę migrowania większej liczby danych, w tym mieszania błędów pobierania, utraty danych mieszania i utraty danych RDD. Migracja danych może również prowadzić do mniejszej ilości ponownego obliczania i zaoszczędzonych kosztów.

Uwaga

Likwidowanie jest najlepszym rozwiązaniem i nie gwarantuje, że wszystkie dane można migrować przed ostatecznym wywłaszczeniem. Likwidowanie nie może zagwarantować awarii pobierania mieszania podczas uruchamiania zadań pobierających dane mieszania z funkcji wykonawczej.

Po włączeniu likwidacji błędy zadań spowodowane wywłaszczeniem wystąpienia typu spot nie są dodawane do całkowitej liczby nieudanych prób. Błędy zadań spowodowane wywłaszczeniem nie są liczone jako nieudane próby, ponieważ przyczyna błędu jest zewnętrzna dla zadania i nie spowoduje niepowodzenia zadania.

Włączanie likwidowania

Aby włączyć likwidowanie w klastrze, wprowadź następujące właściwości na karcie Spark w obszarze Opcje zaawansowane w interfejsie użytkownika konfiguracji klastra. Aby uzyskać informacje na temat tych właściwości, zobacz Konfiguracja platformy Spark.

• Aby włączyć likwidowanie aplikacji, wprowadź tę właściwość w polu konfiguracji platformy Spark:

  spark.decommission.enabled true
  

• Aby włączyć migrację danych mieszania podczas likwidowania, wprowadź tę właściwość w polu konfiguracji platformy Spark:

  spark.storage.decommission.enabled true
  spark.storage.decommission.shuffleBlocks.enabled true
  

• Aby włączyć migrację danych pamięci podręcznej RDD podczas likwidowania, wprowadź tę właściwość w polu konfiguracji platformy Spark:

  spark.storage.decommission.enabled true
  spark.storage.decommission.rddBlocks.enabled true
  

  Uwaga

  Gdy replikacja RDD StorageLevel jest ustawiona na więcej niż 1, usługa Databricks nie zaleca włączania migracji danych RDD, ponieważ repliki zapewniają, że RDD nie utracą danych.

• Aby włączyć likwidowanie procesów roboczych, wprowadź tę właściwość w polu Zmienne środowiskowe :

  SPARK_WORKER_OPTS="-Dspark.decommission.enabled=true"
  

Wyświetlanie stanu likwidacji i przyczyny utraty w interfejsie użytkownika

Aby uzyskać dostęp do stanu likwidacji procesu roboczego z interfejsu użytkownika, przejdź do karty Interfejs użytkownika klastra Spark — wzorzec .

Po zakończeniu likwidowania możesz wyświetlić przyczynę utraty funkcji wykonawczej na karcie Funkcje wykonawcze interfejsu użytkownika platformy Spark > na stronie szczegółów klastra.