NetWorker: Problemy z wydajnością zadania klonowania vProxy w trybie pojemności między domenami danych

• Szybkość klonowania vProxy spadła z GB/s do bardziej tradycyjnych i rzeczywistych prędkości.
• Przepustowość sieci 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 plików *-flat.vmdk dla dysków maszyny wirtualnej, których dotyczy problem, zawierających:
  • synthesized_vbytes 0 i kończący się recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr dla pliku podstawowego, a kończący się na błędzie Dojścia pliku jest przestarzały.
• Komunikaty znalezione w dziennikach akcji klonowania (jeśli poziom debugowania klonowania wynosi 3 lub więcej) odnoszące się do jednego lub większej liczby plików *-flat.vmdk dla dysków dotkniętych maszyną wirtualną zawierających:
  • Replikacji syntetycznej nie można używać dla pliku... path.../vm-vmnumber-disk-key-disknumber-flat.vmdk

VProxy używa wirtualnych syntetycznych elementów w celu wykorzystania zmienionego interfejsu API do śledzenia bloków VMware, zapewniając ogromne korzyści zarówno dla operacji tworzenia kopii zapasowych, jak i klonowania. Wymaga to aktywnej konserwacji wewnętrznych powiązań dziednolić zestawu plików maszyny wirtualnej w każdej danej domenie danych. W przypadku wystąpienia problemów podczas przygotowywania do klonowania przy użyciu wirtualnych syntetycznych narzędzi NetWorker i Data Domain nie mogą wrócić do korzystania z domyślnego przepływu pracy replikacji. Wymaga to przetwarzania całych plików dysków wirtualnych, a nie tylko zmienionych bloków, w przeciwieństwie do zmienionych bloków dostarczonych przez interfejs API VMware. Nawet jeśli z powodu deduplikacji ostatecznie wysłane są małe dane, czas trwania zadania klonowania może być zwiększany przez wielokrotność.
 
Przyczyny, które mogą prowadzić do niepowodzenia wirtualnego śledzenia syntetycznego obejmują:

• Różne adresy IP, które zostały rozwiązane przez NetWorker dla źródłowych lub docelowych urządzeń Data Domain między zadaniami — muszą one pozostać spójne dla śledzenia wewnętrznego wirtualnego syntetycznego
• Zmiana źródłowej lub docelowej domeny danych 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 zapiszeń w łańcuchu
• Więcej niż jeden pakiet zapisu vProxy wymagający klonowania dla danej maszyny wirtualnej, co może prowadzić do nieprawności klonowania savesets w łańcuchu
• Dyski maszyn wirtualnych, które są wydłużone bez żadnych zmian (w szczególności okresy, które przekraczają okresy przechowywania zapisu, takie jak 35 dni bez zmian, w przypadku których przechowywanie wynosi 30 dni)
• Nie można użyć właściwości chronologicznejordera, jeśli używasz NetWorker 19.6 i nowszych

Ze związku z licznymi potencjalnymi przyczynami należy zapoznać się z konfiguracjami Data Domain i NetWorker i zapewnić:

• Ifgroups are setup correctly for source (backup) and destination (clone target) Data Domains (Ifgroups are correctly setup for both source (backup) and destination (clone target) Data Domains
• Serwer NetWorker, węzły pamięci masowej i domeny danych mają wpisy plików hostów przy użyciu odpowiednich adresów IP ifgroup dla domeny danych i niezawodnego DNS dla klientów (korzystanie z plików hostów klienta NetWorker w razie potrzeby).
• Pojedyncza domena danych dla każdej puli kopii zapasowych i klonów.

W przypadku korzystania z oprogramowania NetWorker w wersji 19.5 lub starszej:

• Dopilnowanie, aby zadania klonowania były wykonywane szeregowo i w kolejności kopii zapasowych; Zwróć uwagę, że nie można tego kontrolować, gdy wiele klonów dla danej maszyny wirtualnej znajduje się na tej samej liście zadań (akcja klonowania lub lista plików zapisu nsrclone).
• Upewnij się, że jeden wolumin kopii zapasowej i klonowania na pulę, aby uniknąć jednoczesnego klonowania, gdy dla źródła dostępnych jest wiele woluminów.

W oprogramowaniu NetWorker 19.6 należy zawsze włączać funkcję ChronlogicalOrder dla akcje klonowania vProxy saveset, które mogą być ukryte w interfejsie użytkownika:

• W przypadku korzystania z polecenia nsrclone użyj przełącznika -O, aby wymusić włączenie tej nowej funkcji podczas korzystania z listy zapisów z wieloma ustawieniami zapisu w łańcuchu danego klienta
• Aby włączyć w zasadach, użyj jednego z dwóch poniższych poleceń:

  • nsrpolicy action update clone -p policyname -w workflowname -A actionname [--chronological_order | -l] 

  • W wierszu polecenia nsradmin:

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

    • update Chronological order: Yes

      
       
• Po zakończeniu tych czynności wspomniane wcześniej ograniczenia dotyczące woluminów jednego źródła i lokalizacji docelowej, a także przyrosty wielu instancji na klienta maszyny wirtualnej są podnośane i można je prawidłowo przetwarzać.

WAŻNE: NetWorker i Data Domain mogą wystąpić w pewnych warunkach, w których zapisywanie jest sklonowane poza kolejnością. Powoduje to, że niektóre z nich nie mogą używać VSR do replikacji, ale po przywróceniu całego łańcucha klonowanie VSR może kontynuować bez problemu. Generalnie klonowanie poza kolejnością, klonowanie wielocyzowe i wielo saveset może dogonić i powrócić do normalnej pracy.
 
Jednak w przypadku korzystania z wielu adresów IP domeny danych lub pełnej zmiany źródła lub lokalizacji docelowej Data Domain jedynym sposobem powrotu do regularnej i spójnej optymalizacji VSR jest wymusenie nowej pełnej kopii zapasowej zagrożonych maszyn wirtualnych w celu zresetowania zmienionego śledzenia bloku i przywrócenia optymalizacji VSR. Należy to uwzględnić po wykonaniu poprzednich kroków, ale rejestrowanie data domain i/lub NetWorker, a także szybkość klonowania wskazują, że nadal występują problemy z wydajnością.