Verandering iSCSI-id

[peter1966]

Hi Wij gebruiken 3 Synology NAS oplossingen
1 x 2 stuks RS36145xs+ in HA cluster
1 x DS1815+ main back-up storage
1 x DS1813+ mirror backup storage

Deze 3 Nas oplossingen zijn via iSCSI gekoppeld aan een xenserver virtuele omgeving.

Vorige week wilde wij een update uitvoeren van de virtuele omgeving.
Dit ging gruwelijk mis en wij zijn hierbij door het oog van de naald gekropen. Omdat de back-up ook elders tot replica's leidt van de operationele virtuele machines was het kwijt raken van een fileserver en de back up nog op te vangen.

Na de noodzakelijke reboot van de virtuele hosts bleek dat de host de connectie met de Synology nassen heeft verloren.

Verder onderzoek wijst uit dat dit veroorzaakt wordt door het feit dat de iSCSI-id, vam de Synology NAS(sen) gewijzigd is.
Deze wijziging heeft tot gevolg dat de xenserver hosts na een reboot de verbinding met de storage verliest.

De nieuwe, gewijzigde, iSCSI-id kenbaar maken in de virtuele omgeving bleek de oplossing hiervoor.
Voordat deze oplossing gevonden was waren we , met hulp van het citrix support team, 3 dagen en enkele definiteive data verliezen verder.

Achteraf zou ik graag willen weten wat er toe kan leiden dat de ISCS-ID van de, Synology, storage wijzigt en kan ik de ISCSI-id aan de storage kant uit lezen.

Bij een reboot van alle xenservers in februari deed dit probleem zich nog niet voor.

Is hier iemand die mij verder kan helpen?

Bij voorbaat hartelijke dank

Peter Vroegop

[aliazzz]

De mannen van synology helpdesk contacteren?

[wopper]

Ha Peter

je geeft aan dat je de virtuele omgeving hebt geüpgraded. Heb je daar 100% alle releasenotes van gelezen en de tussenliggende releasenotes? Ik weet vanuit mijn werkervaring dat er bij die grote partijen soms wijzigingen worden vermeld zoals "ISCSI driver updated" maar die worden dan niet in alle releasenotes meer herhaald.

Samenvattend de ID op de synology is hetzelfde gebleven maar jouw Citrix host heeft een andere IQN ID in zijn configuratie opgeslagen waardoor hij niet meer in staat was om te connecten?

Synology zal niet zijn IQN  ID wijzigen omdat de Xenserver gereboot is, ik denk eerder dat de Xenserver zelf zijn config heeft vernield in het upgrade script.

Ja je kunt ze uitlezen DSM -> Storage Manager ->iSCSI Target -> copy IQN (is degene van Synology) / degene die ingelogd is zie je ook vermeld Xenserver.

Altijd 1 host upgraden/rebooten/testen en een week productie draaien voordat je de rest upgrade. Of als je een dualdatacenter hebt zoals mijn klanten eerst DC1 upgraden en en week of een maand later pas DC2.

[peter1966]

Ha Wopper,

Jij hebt het over de IQN daarnaast heeft de storage nog een ID. De bijlage bevat een screenshot met hierop gearceerd de id die ik bedoel.

Deze ID vind ik niet op de beschreven plek terug 

Citrix heeft hier ook een knowledgebase article over geschreven. die wel degelijk vermeld dat deze ID kan wijzigen en hoe dit op te lossen.

Als deze ID wijzigt zal alles door werken tot de server herstart wordt.

Dit is ook wat hier gebeurde bij de eerste server bij de herstart als gevolg van de update, bij beide andere servers tijdens een herstart, zonder update!!!.

Het probleem werd hier dus niet door een update script veroorzaakt.

[wopper]

Hi

ja we bedoelen het zelfde, samenvattend dit probleem ligt niet aan je synology.  Maar jouw XenServer heeft het id gewijzigd voor some reason en na de reboot (tbv de upgrade) is het mis gelopen. Misschien is het weken daarvoor al gewijzigd en is hij in de tussentijd nooit gereboot.

Staat los van de Synology lijkt mij?

[peter1966]

Hi Wopper,

Allereerst bedankt voor het meedenken, maar als ik naar de screenshot kijk ziet de gearceerde regel er heel anders uit dat de info die jij eerder beschrijft in de synology NAS. Wat volgens mij de ISCSI target genoemd wordt.
Deze target staat een aantal regels hoger beschreven in de description.
Deze is gedurende het process van storingen en oplossing ook niet gewijzigd.

Het citrix support team verwijst ook naar de storage als oorzaak van de wijziging.

Als ik jou volg en zo hoor kan de xenserver "zomaar" een ID wijzigen en zichzelf dus de nek omdraaien bij de volgende herstart?

[wopper]

Hoi Peter

ik ken xenserver niet in detail https://support.citrix.com/article/CTX118641 maar niets is onmogelijk. Ik redeneer heel simpel, je bent aan het patchen geweest op de Xenserver en aan het rebooten. Je hebt de NAS'en niet aangeraakt toch? Ik geloof niet dat een NAS in rust, lees in productie, ineens zijn IQN nummer (of ID) gaat aanpassen.

Je kan dit beter door en door testen en kijken of het nog een keer fout gaat, ik heb thuis wel eens gehad dat mijn Windows A server er met de LUN van server B vandoor ging. Doordat ik "autodiscovery" gebruikte...dat is ook niet wat je wilt hebben. Oplossing voor mij was een password per LUN uniek maken aan de servernaam.

[peter1966]

Ha Wopper,
Het door jou aangehaalde artikel heb ik ook gebruikt bij de herstel van het probleem.
Wij zijn namelijk (samen met citrix support) ruim een week aan het troubleshooten geweest.

Alles draait nu weer.

Citrix zegt dat de storingen begonnen zijn door de herstart van de eerste (gepatchte) server.
Na de reboot, kan de server niet meer verbinden omdat SCSI-ID (dus  niet de target) gewijzigd is.
Na de eerste storing en verkeerd troubleshooten zakte het hele systeem als een kaartenhuis in elkaar

Achteraf zien klopt wel dat de servers die nog niet gepatched waren ook na een herstart de mist ingingen.

En inderdaad alles nu goed door testen.
Mijn pool is weer up and running.

Ik heb een identieke testserver gebouwd die ik eerst op het uitgangsniveau (qua hotfixes) gebracht.
Ik heb een test NAS van Synology daar kanik de zaken teten die ik de afgelopen maanden probleemloos heb uitgevoerd kan testen.
Echter tot nu toe geen resultaat. Alles gaat zoals het moet gaan

Het probleem is ook (mede omdat citrix aangeeft dat het probleem bij de storage vandaan komt) Synology gemeld, die zijn nu logs aan het uitpluizen.

Aan alle kanten wordt dus gewerkt om uit te zoeken wat er nu gebeurd is en hoe dit in het vervolg kan worden voorkomen.

Dus nogmaals, bedankt voor het mee denken.

Groet,

Peter

[wopper]

Wat is eruit gekomen Peter? Uit het support onderzoek?


Verzonden vanaf mijn iPhone met Tapatalk

[peter1966]

Na ruim een week gewacht te hebben is er niets uitgekomen:(
De log file vertoont sinds februari geen enkele error of verwijzing naar een iscsi-id change

Waarschijnlijk zal de oorzaak an het probleem dus nooit echt aan het licht komen.

Ik heb wel een en ander getest en uitgevoerd en na herstel van de verbindingen zijn er geen problemen meer geweest.

De werkzaamheden (updates) waarbij het fout ing gan nu wel naar behoren.

Bedankt voor de aandacht en intresse.

Groet,

Pete