Od czasu do czasu napotykam ten artykuł http://www.ibm.com/developerworks/wikis/display/WikiPtype/AIXV53SANBoot, myślę, że ten artykuł zawiera bardzo starą informację, którą należy odświeżyć, doprowadzić do poziomu obecnego stanu technologi SAN. Poniżej jest moje pięć groszy na ten temat.
1. If a SAN hardware problem or an AIX defect causes intermittent loss of access to the SAN, there is no way of capturing a dump to determine what went wrong. The AIX error log and the AIX dump logical volume are in rootvg. If rootvg is on LUNs and AIX can not access LUNs, there is no way to write a dump to the SAN.
Moje pierwsze pytanie: kiedy ostatni raz, któryś z was musiał analizować dump? Żarty na bok, w przypadku środowiska wyposażonego w więcej niż jedną sieć SAN, każda ze swoim własnym zestawem przełączników, SVCs, itp? W takim środowisku maszyna AIX otrzymuje LUNy z każdego SANu, które są następnie “lustrowane” (mirrored) przez LVM. Strata kontaktu z jedną siecią SAN nie powoduje katastrofy, ponieważ rootvg dalej działa – maszyna ma dostęp do lustra z drugiego SANu. Każdy dysk/strona lustra rootvg posiada swój własny tom logiczny typu dump (tego typu tomy nigdy nie powinny być lustrowane niezależnie od użytego typu dysków) i po strace dostępu do jednego SANu, jaki kolwiek <code>dump</code> może być zapisany do dysku, do którego maszyna ma w dalszym ciągu dostęp. Naprawdę, jeżeli maszyna AIX straciła kontakt z siecią SAN to uważam, że mam większe problemy niż stracony dostęp do rootvg – mój główny problem to brak dostępu do danych, które również “żyją” na dyskach dostarczonych przez ten sam SAN, nie jest to oczywiste? Czemu martwić się o niedziałającą rootvg, jeżeli grupy dysków z danymi mogą być “re-zoned” i udestępnione innym maszyną?
2. It is difficult to update the Multipath Subsystem Device Driver (SDD or SDDPCM) or other Fibre Channel multipath I/O support (eg, EMC PowerPath or HDS HDLM) when rootvg is on hdisks accessed via multiple Fibre Channel paths, assuming such multi-path access is supported for rootvg hdisks.
Kilka linijek dalej, znajdziesz następujące stwierdzenie “Nic takego nie następuje używając SDDPCM z MPIO AIXu”. Pamiętam, że kilka lat temu, IBM zaczęło polecać SDDPCM jako metoda preferowana w miejsce SDD. Skożystaj z rady IBM i zainstaluj SDDPCM po czym nie będziesz miał już żadnych problemów odświeżając ten sternik w przypadku maszyny startującej z SAN.
3. Running AIX on LUNs can be the source of some very mysterious AIX behavior if the SAN occasionally injects delays into I/O operations, particularly paging operations. (According to a comment below by xxx xxxxxx, updating SAN zoning will inject delays in some SANs.) And it is certainly the case that AIX hangs lasting several minutes are a big concern in a cluster (HACMP, VCS, etc), where, if a node hangs for a long time and suddenly wakes up, there is the risk of data corruption.
To ostatnie zdanie brzmi naprawdę bardzo tajemniczo. W mojej opinii to zdanie czytane publicznie ma potencjał zabicia SANu lub co najmniej może być odpowiedzialne za zwolnienie tempa akceptacji i adaptacji tej technologii na scalę światową. Jeżeli SAN jest w stanie wprowadzić opóźnienie w operacje I/O to nie ma sensu go używać! Dlaczego mam kupować HACMP, jeżeli SAN powoduje jego bezużyteczność? Dotychczas, używałem SAN z i bez SVC z DSXXXX, EMC, Hitachi i Clarion w środowiskach z kilkoma setkami serwerów WINDOWS i około 80 maszyn AIX z dużą liczbą klasterów HACMP – podczas ostatnich sześciu lat, doświadczyłem opóźnienia będące wynikiem złego rozprowadzenia/przeładowania grup dysków po strone SAN. Około siedmiu lat temu, administrując bezpośrednio połączony z maszyną system dysków typu “fibre”, widziałem opóźnienia będące rezultatem formatowania LUNs – czy artykół ma na uwadze ten rodzaj opóźnień?
4. Accidentally installing AIX on the wrong LUNs or booting a system from the wrong LUNs….
Pracując z dyskami SCSI musisz pamiętać o daniu im indywidualnych adresów, należy umieścić odpowiedniego rodzaju terminator na końcu kabla łączego urządzenia SCSI, itp. …. Czy to jest mniej czy też bardziej skomplikowane niż podłączanie maszyny do sieci SAN? Ja myślę, że SAN jest najmniej skąplikowany ze wszystkich możliwych metod łączenia się z urządzeniami do przechowywania danych.
Konkluzja: Na świecie istnieje setki tysięcy serwerowni gdzie maszyny AIXu startują z sieci oraz/lub używają jej do przechowywania danych innych niż system operacyjny, czy nie myślisz, że ktoś w IBM powinien odświeżyć ten dokument?
AIXuj i dziękuję Tobie za każdy komentarz!!!
Jeff,
I believe, that SAN is a product that requires competent SAN and AIX administrators. If they are not already “seasoned” at least they have to be willing to learn and have enough time to seek the “new”. Like everything else, SAN needs to be understood, researched, drivers need to be current, and so forth.
The delays that I have experienced with Hitachi had nothing to do with the SAN maker. They were the result of me “putting” too many LUNs on the set of disks and them not being able (as the result) to handle the load. Fortunately, increasing the disks queues (on the AIX host) took care of business. The delay was not the mysterious attribute of SAN fabric but “step” in my process of becoming a SAN administrator – the price of learning.
Thanks for you comment, Jeff!
my two cents, I more or less agree with everything stated but we rolled out SAN boot in some development environments a few years back and started to see some strange behavior which turned out to be related to a defect in clariion storage, the end result was not very fun as dozens of LPAR’s would all seize up at the same time and hang for 30-45 seconds.
interestingly, EMC provides a primus document on boot from SAN on AIX pitfalls/gotchas which should be reviewed by anyone rolling this out.
in the end we went to using EMC Sym’s for hosting the LUN’s and presenting them as virtual disks through VIOS to the individual LPAR’s, which works quite nicely.
Hah! Couldn’t agree more. I’ve been saying the same thing for years!
Regarding the HACMP/PowerHA “concerns”. Well, the link below points to a HACMP Flash that certifies HACMP support for p6 Live Partition Mobility. By certifying this support for LPM, HACMP certifies SAN boot support (since as we know this is required for LPM).
And while we are at it. With regard to LPM, the one area to pay special attention to (in regard to the cluster) is the heartbeat rates defined for the HACMP heartbeat networks since any customization that shortened the interval could cause an impact during the LPM migration period. An interesting point to consider when you merge HACMP with LPM is to always maintain cluster node server separation even if the move is short term. You don’t want to create a single point of failure condition.
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10640
Cheers.
CG