jeden ze scénářů existence adresáře clusterstorage.000

Dnes jsem řešil takový zajímavý problém, který hezky demonstruje to, jak je důležité nehrát si s produkčním prostředím.

Prostředí je velice jednoduché: dva Hyper-V servery v clusteru s iSCSI storagem. Konfigurace OS, sítí, Hyper-V atd. naprosto v pořádku a cluster prošel při formování bez ztráty kytičky. Za to musím zákazníka pochválit a ocenit ho dle Červeného trpaslíka hodnocením pět a půl pračky whirlpool.

Bohužel problém nastal ve chvíli, kdy si jeden z kolegů chtěl pohrát s clusterem a připojit si k němu další iSCSI pole. Protože mu to ale pořádně nešlo, tak si začal lehce hrát s kdečím. Finálem byla nemožnost zapnutí několika produkčních VMs z konkrétního CSV disku. Po bližším prozkoumání jsem našel na jednom z nodů adresář ClusterStorage.000, který seděl hned vedle správného ClusterStorage, a obsahoval data nespustitelných VM. Tento adresář (.000) vzniká typicky v případech, kdy cluster node nedokáže úplně jasně určit cestu, kterou se má připojit k datům.

image

 

Jak postupovat? Nejjednodušší způsob (než se začnete vrtat v clusterlogu) je spustit starý dobrý Cluster Validation test na tomto “vadném” CSVčku. V mém případě bylo výstupem následující.

image

A když jsem se pak mrknul na seriáky a signatury, tak byla opravdu vidět duplicita,

image

což jasně s pomocí tohoto screenshotu ukazuje na špatně nastavené (čtěte nenastavené) MPIO.

Jasně, není to nic moc převratného, ale myslím si, že je zajímavé vidět, jak na takto simple věc reaguje WFC.

Written on March 18, 2015