Exchange Cluster und Veritas Volume Manager Probleme

[ketchup73 10]

Hallo

 

ich habe einen Exchange Cluster der über den Volumemanager auf 2 emc San's gespiegelt ist. Jetzt habe ich schon das 2. Mal in 8 Monaten das Problem das mir mitten in der Nacht aus heiterem Himmel die Clusterressource , wo der Exchange drauf läuft einfach alles verliert. Sprich ich komme in der Früh und die Platte ist leer. Sprich kein Dateiformat daruf oder ähnliches. Leider finde ich in keinem Log irgendwelche Hinweise was passiert sein koennte. Es schaut fuer mich aus das ein bite gekippt ist und Windows seine Partitiontable verloren hat. Beim ersten mal und auch bei diesem Mal ict kurz davor eine Platte in einer EMC ausgefallen und Veritas Volume Manager wollte einen resync.

Hatte jemand schon so ein Problem ? Hatte jemand schon so einen Vorfall ? Bin auf der Suche nach der Ursache. Vermute das es an einem bug bei der emc liegt.

Wäre nett wenn jemand mir ein paar infos geben koennte

[Lian 2.465]

Hallo,

 

welches Log hast Du geprüft?

 

Das cluster.log?

 

Wenn Du dort keinen Fehler findest (WARN oder ERR) und das Event log sauber ist, könntest Du Recht haben mit Deiner Vermutung, daß es am Veritas VM oder der EMC liegt.

Es könnte Dir aber auch ein anderer Filtertreiber einen Streich spielen.

 

Welche sonstigen File System Filtertreiber auf dem System, wie zB. AntiVirus, Quota etc., installiert sind, siehst Du im Gerätemanager oder über den Befehl "devcon".

 

Setz mal folgenden Befehl in der CMD ab und poste bitte das Ergebnis:

 

devcon listclass LegacyDriver

 

devcon ist in den Support Tools oder direkt bei MS zu finden, mehr dazu:

Siehe: Cluadmin.de Windows Cluster Blog » Blog Archiv » Filtertreiber im Cluster

[ketchup73 10]

morgen

ist jetzt wieder um die selbe uhrzeit passietrt

hab jetzt über windbg den memorydmp von gestern ausgelesen

der sagt mir vxio.sys

hat jemand damit erfahrung oder eine idee woran es liegen kann

[ketchup73 10]

Kann mir irgendwer das erklaeren

 

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

 

IRQL_NOT_LESS_OR_EQUAL (a)

An attempt was made to access a pageable (or completely invalid) address at an

interrupt request level (IRQL) that is too high. This is usually

caused by drivers using improper addresses.

If a kernel debugger is available get the stack backtrace.

Arguments:

Arg1: 11cc110e, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000001, value 0 = read operation, 1 = write operation

Arg4: e1046a61, address which referenced memory

 

Debugging Details:

------------------

 

 

WRITE_ADDRESS: 11cc110e

 

CURRENT_IRQL: 2

 

FAULTING_IP:

nt!MiQueryAddressState+37e

e1046a61 804f0e01 or byte ptr [edi+0Eh],1

 

CUSTOMER_CRASH_COUNT: 1

 

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

 

BUGCHECK_STR: 0xA

 

PROCESS_NAME: Idle

 

LAST_CONTROL_TRANSFER: from e10515e7 to e1046a61

 

STACK_TEXT:

e10a320c e10515e7 fce1b398 00000000 fc15e7a0 nt!MiQueryAddressState+0x37e

e10a3234 f5b1d193 fc920720 00000100 18ffeabd nt!FsRtlAddBaseMcbEntry+0xde

WARNING: Stack unwind information not available. Following frames may be wrong.

e10a324c f5b311a1 fc51f500 00000000 00010000 vxio+0x4193

e10a32d4 f5b3ceac fc920720 e10a3318 e10a3324 vxio+0x181a1

e10a32f4 f5b1a6f2 fc920720 e10a3318 e10a3324 vxio+0x23eac

e10a3374 e103ec8a fcc56030 fcffdd30 fd961520 vxio+0x16f2

e10a33a4 f59607ab e10a33d4 f5960ba9 fe3e8030 nt!ExAllocatePoolWithQuotaTag+0x61

e10a33ac f5960ba9 fe3e8030 fcffdd30 00000001 CLASSPNP!ClassCompleteRequest+0x11

e10a33d4 e103ec8a 00000000 fce38e48 fcf7aed8 CLASSPNP!TransferPktComplete+0x1fd

e10a3404 f5bb19d5 fe3ec248 fbb5d230 fe3ec260 nt!ExAllocatePoolWithQuotaTag+0x61

e10a3430 f5bac559 00000000 fce38e48 fce38f24 EmcpBase+0x99d5

e10a344c f5bac6b8 fe42253c fe4224d8 00000000 EmcpBase+0x4559

e10a34bc e103ec8a fe426310 00e38e48 fbb5d230 EmcpBase+0x46b8

e10a34ec f5a8251f fe50ba30 fce38e48 e10a3530 nt!ExAllocatePoolWithQuotaTag+0x61

e10a34fc f5a81a7c fd595828 00000001 00000000 SCSIPORT!SpCompleteRequest+0x5e

e10a3530 f5a811d8 fe50ba30 fd595828 e10a35a7 SCSIPORT!SpProcessCompletedRequest+0x6a7

e10a35a8 e103eb0f fe50b9ec fe50b978 00000000 SCSIPORT!ScsiPortCompletionDpc+0x2bd

e10a3600 e103ac1f 00000000 0000000e 00000000 nt!NtAllocateVirtualMemory+0x14f1

e10a6b40 00000000 e10a6b48 e10a6b48 e10a6b50 nt!RtlpRunTable+0x2ff

 

 

STACK_COMMAND: kb

 

FOLLOWUP_IP:

vxio+4193

f5b1d193 ?? ???

 

SYMBOL_STACK_INDEX: 2

 

FOLLOWUP_NAME: MachineOwner

 

MODULE_NAME: vxio

 

IMAGE_NAME: vxio.sys

 

DEBUG_FLR_IMAGE_TIMESTAMP: 418b16cc

 

SYMBOL_NAME: vxio+4193

 

FAILURE_BUCKET_ID: 0xA_W_vxio+4193

 

BUCKET_ID: 0xA_W_vxio+4193

 

Followup: MachineOwner

kerneld.dmp.txt

[ketchup73 10]

und hier noch mal ein ausführlich dump

 

 

 

WRITE_ADDRESS: 0000035e

 

CURRENT_IRQL: 2

 

FAULTING_IP:

nt!MmUnlockPages+da

e1042485 f00fc101 lock xadd dword ptr [ecx],eax

 

DEFAULT_BUCKET_ID: DRIVER_FAULT

 

BUGCHECK_STR: 0xA

 

PROCESS_NAME: Idle

 

TRAP_FRAME: e10a3168 -- (.trap ffffffffe10a3168)

ErrCode = 00000002

eax=ffffffff ebx=fc52f154 ecx=0000035e edx=fe7dd560 esi=fc52f138 edi=00000000

eip=e1042485 esp=e10a31dc ebp=e10a320c iopl=0 nv up ei pl nz na po nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202

nt!MmUnlockPages+0xda:

e1042485 f00fc101 lock xadd dword ptr [ecx],eax ds:0023:0000035e=????????

Resetting default scope

 

LAST_CONTROL_TRANSFER: from e1042485 to e1037ed5

 

STACK_TEXT:

e10a3168 e1042485 badb0d00 fe7dd560 3f70007f nt!KiTrap0E+0x2a7

e10a320c e10515e7 fc52f138 00000000 fccdddc0 nt!MmUnlockPages+0xda

e10a3234 f5b1d193 fca82ca0 00000100 18ffeabd nt!IopfCompleteRequest+0x211

WARNING: Stack unwind information not available. Following frames may be wrong.

e10a324c f5b311a1 fd503860 00000000 00010000 vxio+0x4193

e10a32d4 f5b3ceac fca82ca0 e10a3318 e10a3324 vxio+0x181a1

e10a32f4 f5b1a6f2 fca82ca0 e10a3318 e10a3324 vxio+0x23eac

e10a3374 e103ec8a 00000000 fcd92278 fc992008 vxio+0x16f2

e10a33a4 f59607ab e10a33d4 f5960ba9 fe3e2030 nt!IopfCompleteRequest+0xcd

e10a33ac f5960ba9 fe3e2030 fcd92278 00000001 CLASSPNP!ClassCompleteRequest+0x11

e10a33d4 e103ec8a 00000000 fc2e0678 fc25fd48 CLASSPNP!TransferPktComplete+0x1fd

e10a3404 f5bb19d5 fe3e1d58 fc34c008 fe3e1d70 nt!IopfCompleteRequest+0xcd

e10a3430 f5bac559 00000000 fc2e0678 fc2e0754 EmcpBase!PowerTopSyncIoStart+0x75

e10a344c f5bac6b8 fe401cdc fe401c78 00000000 EmcpBase!PowerTopSyncIoFinish+0x26d

e10a34bc e103ec8a fe423cf0 002e0678 fc34c008 EmcpBase!PowerTopSyncIoFinish+0x3cc

e10a34ec f5a8251f fe50a0e8 fc2e0678 e10a3530 nt!IopfCompleteRequest+0xcd

e10a34fc f5a81a7c fd058e20 00000001 00000000 SCSIPORT!SpCompleteRequest+0x5e

e10a3530 f5a811d8 fe50a0e8 fd058e20 e10a35a7 SCSIPORT!SpProcessCompletedRequest+0x6a7

e10a35a8 e103eb0f fe50a0a4 fe50a030 00000000 SCSIPORT!ScsiPortCompletionDpc+0x2bd

e10a3600 e103ac1f 00000000 0000000e 00000000 nt!KiRetireDpcList+0xca

e10a3604 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x37

 

 

STACK_COMMAND: kb

 

FOLLOWUP_IP:

vxio+4193

f5b1d193 6a60 push 60h

 

SYMBOL_STACK_INDEX: 3

 

FOLLOWUP_NAME: MachineOwner

 

MODULE_NAME: vxio

 

IMAGE_NAME: vxio.sys

 

DEBUG_FLR_IMAGE_TIMESTAMP: 418b16cc

 

SYMBOL_NAME: vxio+4193

 

FAILURE_BUCKET_ID: 0xA_W_vxio+4193

 

BUCKET_ID: 0xA_W_vxio+4193

 

Followup: MachineOwner

---------

kerneldmp_gross.txt

[gysinma1 13]

Hallo

 

Die vxio.sys gehört ja zu der Bakup Suite. Ich hatte mal was ähnliches allerdings mit einem SQL Loadbalancer Cluster an SAN (HP MSA1500). Ursache war ein defektes Disksystem auf der Database wo die MSSQL MDFS (also die DBS lagen).

 

Hatten das mit checkdisk (! bei einem Cluster muss die Disk im Maintmode sein !) gelöst. Wir hatten das Problem trotz "tatkröftiger" Hülfe von Microsoft und v.a. HP gelöst. Symptomatisch war auch, dass der Switch bis zu 35 Minuten daurte (im Leerlauf). Im CLusterlog war damals auch nix festzuestellen, ausser ab und zu occured time out, resource not online.

 

Wie sind die Disks partitioniert ... Mdb und Transactionlogs getrennt oder zusammen ... (kann mir zwar nit vorstellen, dass es von dem store ist).

 

Gruss,

MAtthias

[ketchup73 10]

Hi

vielen Dank für die Infos

nur verstehe ich die nicht ganz

kannst du bitte vielleicht ein bischen ausführlicher beschreiben was du meinst bzw gemacht hast

sorry bin seit 3 uhr in aer arbeit und zermarter mir den kopf

ich denke mal das es was mit der san zu tun hat.

hast du auch veritas volume manager im eisatz ?

[gysinma1 13]

Hallo

 

Nein wir hatten ein gänzlich anderes Environment HP SAN (MSA 1500) mit DataProtector 6.0 .

 

Ich vermute die Ursache nicht bei dem Diskagent sondern eher evtl. im Disksystem oder im SAN Bereich. Wie äussert sich das mit "Weg". Keine Volumen mehr, keine Partitionen mehr oder einfach leere Platten ... welche partitioniert werden müssen (wichtig wäre noch zu wissen, will das OS die Disk neu initialisieren oder nit). Wir hatten noch Inhalte konnten aber die Drives nicht mehr mounten.

 

Ich würde sonst auch den EMC Support beiziehen - nimms bitte nicht persönlich mit einem durchgeackerten Kopp bist Du auch nicht mehr der fitteste (evtl. machst Du auch Fehler) und auf einem SAN hast Du meist mehr als 10 Leutchen. Die haben vielleicht noch Inputs oder "frische" Ideen. (Ich rede da wirklich aus Erfahrung !).

 

 

Gruss,

Matthiass

[Lian 2.465]

Denke auch, daß es am vxio.sys liegt.

 

DEFAULT_BUCKET_ID: DRIVER_FAULT

 

MODULE_NAME: vxio

 

IMAGE_NAME: vxio.sys

[ketchup73 10]

@gysinma1

 

der kopf wird immer schwerere , vor allem die augenlieder:D

 

@Lian

ja der meinung bin ich nicht mehr ganz

 

 

@alle

super vielen dank für deine hilfe

fakt ist das laufwerk ist gemountet aber nicht formatiert. wenn du mit windows drauf willst fragt er dich ob er es formatieren soll.

da in letzter zeit weder treiber noch patches eingespielt wurden glaub ich nicht ganz dran das es der volumemanager ist.

komisch ist auch das es anscheinend immer um dieselbe zeit passiert. da wir da keinen task laufen haben tippe ich mal auf das backup

heute früh wuerde das starten des backups und das abrauchen des systems genau übereinstimmen.

finde aber nichts grossartiges in den logs

haben überlegt bei ms einen call aufzumachen, glaub aber das ich als allererstes zu hörenbekomme das ich den server patchen muss, und das wil ich nicht unbedingt

[Lian 2.465]

@Lian

ja der meinung bin ich nicht mehr ganz

 

:suspect:

Was meinst Du damit?

[ketchup73 10]

ich meine damit das es logisch nicht sein kann da ja da nichts verändert worden ist. kann natuerlich auch sein das ich falsch liegen, bin ja leider auch nicht gott

 

hat jamend erfahrung mit netbackup auf unix das windows bze windows cluster sichert

 

komisch ist das in letzter zeit die backup und restore zeiten tierisch langsam geworden sind

kann es sein das da ein problem ist

 

bin mitlerweile immer ratloser

 

wenn einer einen spzialisten weis

ms 2003 exchange cluster mit veritas volume manager und veritas netbackup an einer emc san mit einem sun backup roboter

bitte gebt mir einen tip wie ich den erreichen kann

[Velius 10]

Hi

 

Wie wär's mit

 

---------------------------

start -> ausführen -> 'start devmgmt.msc' eintippen -> [ENTER]

---------------------------

 

...und dann unter 'Ansicht' 'Ausgeblendete Geräte anzeigen' auswählen. Anschliessend unter 'nicht-PnP-Treiber' den vxio.sys Treiber versuchen zu finden.

 

Du müsstest mal kucken, welche Version des Treibers es ist, und ob er von Microsoft Zertifiziert ist. Wenn nicht, hier gäbe es einen:

 

VERITAS Storage Foundation 4.3 for Windows - Windows Hardware Quality Labs logo and digitally signed VXIO.SYS

 

 

Würde aber das ganze nicht ohne Sicherung machen.:wink2:

 

 

Gruss

Velius

[ketchup73 10]

hi

 

den finde ich da leider nicht

[Velius 10]

Dann vielleicht mal nach der Datei suchen auf der Disk, dann rechte Maustaste und Eigenschaften, den Reiter 'Version' mit der Datei aus dem download vergleichen. Wenn die Datei des Dowloads neuer ist wäre es ein Versuch wert.