NetWorker: Tryb pojemności Problemy z wydajnością zadania klonowania vProxy pomiędzy domenami danych

• Prędkość klonowania vProxy spadła z GB/s do bardziej konwencjonalnych i realistycznych prędkości.
• Przepustowość sieci jest wykluczona jako przyczyna wąskiego gardła, pozostając znacznie poniżej progu podczas klonowania.
• Komunikaty znajdują się w ddfs.Dzienniki informacji odnoszące się do jednego lub większej liczby *-flat.vmdk pliki dla dysków maszyn wirtualnych, których dotyczy problem, zawierające:
  • synthesized_vbytes 0 i kończąc na recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr dla pliku podstawowego i kończący się błędem Uchwyt pliku jest nieaktualny.
• Komunikaty znalezione w dziennikach akcji klonowania (gdy poziom debugowania klona wynosi 3 lub wyższy) odwołujące się do co najmniej jednego pliku *-flat.vmdk dla dysków maszyny wirtualnej, których dotyczy problem, zawierają:
  • Nie można użyć replikacji syntetycznej dla pliku... ścieżka.../vm-numer-dysku-klucz-numer-dysku-płaski.vmdk

vProxy wykorzystuje wirtualne syntetyczne do wykorzystania interfejsu API śledzenia zmienionych bloków VMware, zapewniając ogromne korzyści zarówno w operacjach tworzenia kopii zapasowych, jak i klonowania. Wymaga to aktywnego utrzymywania wewnętrznych skojarzeń dziedziczności zestawu plików maszyny wirtualnej w każdej Data Domain. Jeśli podczas przygotowywania do klonowania przy użyciu wirtualnych syntetycznych wystąpią problemy, NetWorker i Data Domain powrócą po awarii do korzystania z domyślnego przepływu pracy replikacji. Wymaga to przetworzenia całych plików dysków wirtualnych, a nie tylko zmienionych bloków, w przeciwieństwie do tylko zmienionych bloków udostępnianych przez interfejs API VMware. Nawet jeśli z powodu deduplikacji zostanie ostatecznie wysłana niewielka ilość danych, czas trwania zadania klonowania może wydłużyć się wielokrotnie.
 
Przyczyny, które mogą prowadzić do awarii wirtualnego śledzenia syntetycznego, obejmują:

• Różne adresy IP, które są rozpoznawane w NetWorker dla źródłowych lub docelowych urządzeń Data Domain między zadaniami. Muszą one pozostać spójne dla wewnętrznego śledzenia wirtualnych syntetyków
• Zmiana źródłowej lub docelowej domeny danych Data Domain dla kopii zapasowych lub klonów vProxy
• Wiele woluminów źródłowych lub docelowych dla kopii zapasowych lub klonów vProxy, co może prowadzić do jednoczesnego klonowania wielu zestawów zapisów w łańcuchu
• Więcej niż jeden zestaw zapisów vProxy wymagający klonowania dla danej maszyny wirtualnej, co może prowadzić do nieuporządkowanego klonowania zestawów zapisów w łańcuchu
• Dyski maszyn wirtualnych, które działają przez długi czas bez żadnych zmian (w szczególności okresy, które przekraczają okresy przechowywania zestawu zapisów, takie jak 35 dni bez zmian, w których przechowywanie wynosi 30 dni)
• Nie można użyć właściwości ChronologicalOrder Action

Ponieważ istnieje wiele potencjalnych przyczyn, przejrzyj konfiguracje Data Domain i NetWorker i upewnij się, że:

• ifgroupDomeny danych są prawidłowo skonfigurowane zarówno dla domeny źródłowej (kopia zapasowa), jak i docelowej (docelowej klona)
• Serwer NetWorker, węzły pamięci masowej i domeny danych mają wpisy plików hostów przy użyciu odpowiednich ifgroup Adresy IP na Data Domain i niezawodny DNS dla klientów (korzystanie z klienta NetWorker hostuje pliki w razie potrzeby).
• Jedna domena danych dla każdej puli kopii zapasowych i klonów.

Włącz funkcję ChronologicalOrder dla akcji klonowania zestawu zapisu vProxy, które mogą być ukryte w interfejsie użytkownika:

• Jeśli używasz nsrclone polecenie, użyj polecenia -O Przełącz się, aby wymusić tę nową funkcję podczas korzystania z listy zestawów zapisu z wieloma zestawami zapisu w danym łańcuchu klienta
• Aby włączyć w zasadach, użyj jednego z następujących dwóch poleceń:

nsrpolicy action update clone -p policyname -w workflowname -A actionname [--chronological_order | -l] <yes|no>

• W wierszu polecenia nsradmin:

. type nsr protection policy action; policy name: policy; workflow: workflow: name: action

update Chronological order: Yes

• Po zakończeniu tej czynności wspomniane wcześniej ograniczenia dotyczące woluminów z jednym źródłem i miejscem docelowym, a także przyrostów z wieloma wystąpieniami na klienta maszyny wirtualnej, są znoszone i mogą być prawidłowo przetwarzane.

WAŻNE: W niektórych warunkach możliwe może być odzyskanie danych NetWorker i Data Domain, gdy zestawy zapisów są klonowane poza kolejnością. Powoduje to, że niektórzy nie mogą używać VSR do replikacji, ale po przywróceniu całego łańcucha klonowanie VSR może przebiegać bez problemu. Ogólnie rzecz biorąc, klonowanie poza kolejnością, klonowanie wielu woluminów i wiele zestawów zapisu może nadrobić zaległości i powrócić do normalnego działania.
 
W przypadku, gdy wiele adresów IP Data Domain zostało już użytych lub całkowicie zmieniło źródło lub miejsce docelowe Data Domain, jedynym sposobem powrotu do regularnej i spójnej optymalizacji VSR jest wymuszenie nowej pełnej kopii zapasowej maszyn wirtualnych, których dotyczy problem, w celu zresetowania śledzenia zmienionych bloków i przywrócenia optymalizacji VSR. Należy to uwzględnić po wykonaniu poprzednich kroków, ale rejestrowanie danych Data Domain i/lub NetWorker oraz szybkość klonowania wskazują, że problemy z wydajnością nadal występują.