Onderwerp: Stabiliteit SAN testen

Ik draai nu een poosje een Dell R510 in productie, direct (dus zonder switch) gekoppeld aan een Dell R310 met enkele VM's (web- mailservers). Ik wil nu de stap gaan maken om ook db servers te gaan draaien. In de afgelopen maanden heb ik één rare storing gehad, namelijk dat alle VM's in read only stonden.

De oorzaak daarvan is hoogstwaarschijnlijk wegens het feit dat de MTU op de SAN op 1500 stond, en op de R310 stond deze op 9216. Vreemd is wel dat dit slechts 1 keer is voorgekomen terwijl deze instelling maanden zo heeft gestaan. Nu staat hij op beide servers op 1500.


Nu is mijn vraag; wat kan ik naast een paar maanden gedraaid te hebben, nu echt gaan testen of de huidige configuratie stabiel genoeg is voor meer belasting?

Zelf draai ik meestal een aantal VM's met de Phoronix Test Suite tegelijk

http://www.phoronix-test-suite.com/

Ik ga er naar kijken, heb jij daar een speciaal script voor geschreven?

*kick

Als de VM's in read only stonden, is er enige tijd helemaal geen I/O meer mogelijk geweest. Na een bepaalde timeout worden de filesystems dan read only gemount. Ik kan me haast niet voorstellen dat het door een verkeerde MTU komt, maar een onjuiste MTU kan wel vage dingen veroorzaken, dus dat fixen is sowieso slim geweest natuurlijk Maar ik zou wel even goed de logs op de systemen die de iSCSI verbinding opzetten nakijken (dus waarschijnlijk je clusternode).

Hetzelfde geld voor de nfs shares

Over de MTU; Waarom heb je nu alles op 1500 staan en niet op 9216? Je overhead is nu hoger dan noodzakelijk....

Oorspronkelijk geplaatst door Paul Z.

Over de MTU; Waarom heb je nu alles op 1500 staan en niet op 9216? Je overhead is nu hoger dan noodzakelijk....

Natuurlijk kun je kiezen voor Jumbo frames (MTU 9000), maar dan moeten wel alle apparaten dat goed ondersteunen. Anders krijg je rare dingen zoals verlies of fragmentatie - en dat wil je zeker niet.

Oorspronkelijk geplaatst door PimEffting

Natuurlijk kun je kiezen voor Jumbo frames (MTU 9000), maar dan moeten wel alle apparaten dat goed ondersteunen. Anders krijg je rare dingen zoals verlies of fragmentatie - en dat wil je zeker niet.

Ik weet dat dit aangeraden wordt voor de communicatie tussen newsservers (grote datastromen, forse grote pakketten) , voor DBs lijkt me dit juist een erg slecht plan.

Oorspronkelijk geplaatst door vDong

Ik weet dat dit aangeraden wordt voor de communicatie tussen newsservers (grote datastromen, forse grote pakketten) , voor DBs lijkt me dit juist een erg slecht plan.

Want ?

Als je een apart storagenetwerk hebt is het tegenwoordig meestal geen probleem om Jumbo Frames te gebruiken. Bijna alles ondersteunt het wel.

Toch vandaag weer alle KVM's in READ-ONLY.... frustrerend! Helemaal vreemd omdat de SAN direct is verbonden met de R310!

Iemand die mij verder op weg kan helpen?

Klinkt als of de connectiviteit langer dan XX seconden is verloren, dat heb ik vaker zien gebeuren met vm's die dan automatisch in read-only gaan staan. Het kan zijn dat je networking niet lekker werkt en af en toe aan het haperen is, je kan bijvoorbeeld de disk time-out verhogen op OS niveau in een vm of actief je iscsi network gaan monitoren (maar ik neem aan dat je dat al doet). Als je gebruik maakt van multipathing, dan kan het zo zijn als een NIC kapot is dat je ook zulk gedrag kan krijgen, er komen immers tijdelijk geen of halve packets aan.

Daarnaast is de r510 geen SAN, welke storage software draai je er ook alweer op?

kleine edit: ik lees er over heen dat je DAS gebruikt en geen iscsi, bovenstaande verhaal gaat dan niet op. Wel handig voor anderen met dergelijke symptonen. Controleer als nog je sas cables en je raid controllers.

Wat gaven de virtuele machines aan? Hadden die I/O timeouts, waarna het FS readonly werd gemount? Of is er misschien sprake van filesystem corruptie (is dan ook te zien op de console van de VM's).

In geval van timeouts, wat staat er in de logs van de node?

De MTU zou ik controleren en op 9k zetten (waar mogelijk). MTU problemen kunnen zorgen voor een instabiel netwerk in bepaalde gevallen, met goede MTU instellingen ervaren wij zelf (wel op andere hardware) dat alles stabiel is (en met lage MTU waardes was het instabiel/traag).