artykuły dotyczące funkcjonalności są zazwyczaj mieszaniną zachwytu oraz wizji jak to teraz będzie cudownie. można się z nich dowiedzieć że coś jest i mniej-więcej o co cho, niemniej pod względem wartości – są tylko wstępem do rzeczy całej. dla tego najbardziej lubię arty krytykanckie [ale nie hejterskie!], ponieważ to w nich odnajduje się ostrzeżenia, ograniczenia, potencjalne problemy czy nieobsługiwane scenariusze. nawiązując zatem do trendu kilka rzeczy, na które należy zwrócić uwagę przy korzystaniu z SS.

limity i inne takie

  • SS pozwala na założenie volumenu logicznego o wartości przekraczającej dostępną wielkość fizyczną. [nie testowałem, ale ponoć] jest w bug w SS, w wyniq którego przy osiąganiu górnych limitów zużycie CPU peakuje a dostęp się zawiesza. generalnie uważam, że tworzenie dysq logicznego większego niż fizyczna przestrzeń w produkcji, to strzał w kolano. zawsze można potem łatwo zrobić ‚extend’ więc po co tak ryzykować? bo przecież…
  • …kiedy przestrzeń kończy się na dyskach fizycznych, volumen SS jest wyłączany.
  • po wybraniu trybu działania volumenu [single/mirror/parity] – ustawienia nie da się zmienić. w sumie to normalne dla każdego RAIDu… inne zasady dotyczące odzyskiwania/przenoszenia danych na fizycznych dyskach również obowiązują – nie da się wyjąć pojedynczego dysq i z niego coś odczytać. cały system działa na poziomie ‚block level’ i dane są rozdystrybuowane na wszystkie dyski.
  • jeśli wybierze się tryb ‚mirror’, a wielkości dysqw nie są takie same, to traci się całą pozostałą przestrzeń. mirror wymaga równych kawałków, a więc jeśli mamy pool z 3 dysqw – 5,1o i 2o GB, to fizycznie będzie to RAID na 3x5GB [no… trochę kłamię – szczegóły w FAQ]. dla użytkownika de facto będzie jeszcze mniej, bo odpadają parzystości. jedną z najistotniejszych rzeczy, o których należy pamiętać w pracy z SS jest właśnie fakt, że pod spodem działają normalne algorytmy wyliczania parzystości znane z RAID. w związq z tym ustalając maxymalną wielkość volumenu logicznego należy pamiętać o tym, że fizycznie to nie jest prosta suma dostępnych dysków fizycznych. IMHO to spory ból, że nie ma dostępnego jakiegoś kalqlatora podczas tworzenia volumenu [jest w w8 a nie ma w w12 /: ], który pokazuje max fizycznej dostępnej wielkości… szczerze powiedziawszy to nie wiem jak to w ogóle sprawdzić na serwerze O_o
  • minimalną wielkością dysq obsługiwaną przez SS jest 4GB
  • cluster nie obsługuje SS fizycznych RAIDów – pool musi być utworzony z fizycznie podłączonych dysków SAS, wyłącznie z fixed provisioning i tryb parzystości mirror lub simple [nie obsługuje parity]
  • braqje sensownego systemu notyfikacji…

kilka fajnych zmian pojawia się w wersji R2 – zwłaszcza Automatic Tiering. niemniej powyższe ograniczenia zostają.

ot taka ciekawostka na koniec – próba skopiowania pliq na volumen, który fizycznie już nie ma miejsca:

 

#REFS

eN.