Przeciążenie systemu dyskowego w trakcie wykonywania backupu może skutkować wieloma nieprzyjemnymi błędami. Jednym z nich jest SCSI Command Abort, pojawia się on w momencie, gdy karta HBA jest przeciążona lub gdy jej kolejka rozkazów (q-depth) zostaje przepełniona. W obu przypadkach skutek jest ten sam, w subsystemie SCSI hosta polecenia SCSI które nie zostaną wykonane w zadanym czasie zostają skasowane. Oznacza to dramatyczny spadek wydajności i wzrost opóźnień w milisekundach. Przyjęta metoda backupu w środowiskach wirtualnych, gdzie odczytujemy VM z jednego miejsca i zapisujemy jej dane w innym miejscu powoduje, że w trakcie backupu musimy przetworzyć bardzo duże ilości danych. Nieprawidłowe lub niefrasobliwe ustawienia (np. schedulerów) mogą spowodować przeciążenie całej infrastruktury SAN w naszym środowisku.
Każdy system monitoringu naszych datastore pokaże nam opóźnienia w milisekundach jakie występują normalnie i w trakcie wykonywania backupu. Nie każdy jednak pokaże czy w naszym systemie występują “Datastore Commad Aborts” (czy ktoś wie jak uzyskać taką informację w vRealize Operations?). Tutaj bardzo pomocny okazuje się Veeam ONE który w takim wypadku wysyła do nas maile z ostrzeżeniami.
Możemy też w trakcie backupu podglądać w czasie rzeczywistym co dzieje się na każdym ESXi, wykorzystujemy do tego esxtop. Po jego uruchomieniu wybieramy “u” aby przejść do sekcji dyskowej a następnie “f”. Tutaj zaznaczamy “L” (czyli błędy), “G” (statystyki rozkazów) i “A” (nazwy dysków), resztę możemy odznaczyć. Normalna praca wygląda mniej więcej tak (przedostatnia kolumna to aborty):
ABRTS/s równe 1 pojawia się wtedy gdy system operacyjny VM zgłasza błąd “brak odpowiedzi dysku” (np. gdy w Windows przez 60 sekund dysk nie akceptuje ani jednej operacji I/O). Jak się przed tym bronić? Jeżeli mamy wiele volumenów, rozłóżmy maszyny wirtualne (te które będą jednocześnie backupowane) równomiernie pomiędzy nie. Na podstawie danych historycznych w Veeam ONE (Datastore –> Disk Issues –> Past week) możemy ustalić który datastore generuje najwięcej błędów i go odciążyć (na podstawie alertów można ustalić które konkretne maszyny zgłaszały błędy w dostępie do dysków).
Ustawmy wyzwalanie backupów tak aby nie zachodziły na siebie. Jeżeli mamy Veeam Backup Enterprise to w opcjach możemy włączyć “Enable storage latency control”.
Pierwszy parametr spowoduje, że Veeam zaczeka na datastore aż będzie niezbyt obciążony zanim wystartuje kolejne zadanie (dlatego należy precyzyjnie ustalić jaka jest nasza średnia). Drugi parametr dotyczy już uruchomionych zadań, jeśli obciążenie datastore przekroczy założony próg to zadanie backupu będzie zwalniać (potrwa trochę dłużej ale nie obciąży datastore ponad miarę). Właściwe dopasowanie progów zależy oczywiście od rezultatu jaki chcecie osiągnąć. Kolejnym parametrem jakim możemy manipulować to “Max concurent tasks” w VMware Backup Proxy.
Domyślna wartość to cztery, możemy ją obniżyć tak, aby osiągnąć równowagę (nie obciążamy datastore nadmierną ilością jednoczesnych zadań i nie wydłużamy backupu ponad miarę). Jeśli to nie pomoże to w opcjach możemy całkowicie wyłączyć “Enable parallel processing”, wtedy backupy będą szły sekwencyjnie. Ostatecznie zwróćmy też uwagę czy w trakcie okna backupowego nie idą inne zadania powodujące dodatkowe obciążenie systemów dyskowych (np. nocna kompilacja kodu). Jak widać możliwości jest wiele, bez trudu da się ustawić backup tak, aby w środowisku nie pojawiały się błędy SCSI.