Y donde esta el Cluster??

Estaba pensando en un lindo articulo sobre SQL Server tranquilamente frente a mi linda note cuando recibo una llamada telefonica, un Exchange 2010 habia perdido el DAG y las bases de datos no montaban.

Ok, quizas sea un caso interesante asi que acepte el desafio y manos a la obra viendo de que se trataba.

Efectivamente las bases estaban abajo, el DAG a simple vista se veia ok, sin embargo no se podia editar ni hacer nada, el error enviado era que no podia contactar el servicio de cluster.

Bien, vamos a mirar como esta el cluster......

El cluster .....

:S

No hay Cluster! Desaparecio, Uups!

[PS] C:\Windows\system32>Get-DatabaseAvailabilityGroup -Identity  'DAG1' -Status

Error en una operación de Active Manager. Error en la operación de clúster. Error: Error en la API de clúster 'OpenByNames('nodo1.dominio.com', 'nodo2.dominio.com') failed for each server. Specific exceptions: 'Error en una operación de Active Manager.

Error en la operación de clúster. Error: Error en la API de clúster '"OpenCluster(nodo1.dominio.com) error con 0x6d9. Error: No hay más extremos disponibles desde el asignador de extremos"'.', 'Error en una operación de Active Manager.

Error en la operación de clúster. Error: Error en la API de clúster '"OpenCluster(nodo2.dominio.com) error con 0x6d9. Error: No hay más extremos disponibles desde el asignador de extremos"'.'.'.

    + CategoryInfo          : InvalidArgument: (:) [Get-DatabaseAvailabilityGroup], AmClusterApiException
    + FullyQualifiedErrorId : 62F1FD80,Microsoft.Exchange.Management.SystemConfigurationTasks.GetDatabaseAvailabilityGRoup

(Odio los mensajes en español, no entiendo nada!!)

He ahi la causa del problema, desaparecio el Cluster y el DAG seguia haciendo referencia a el, bueno, ya tenia la causa del problema, ahora a encontrar la solucion.

Comence a buscar por internet y no encontre nada relacionado con el tema, y si trato de recrear el cluster "a mano"?? mmm a buscar info de como hacerlo, nop, el cluster no existia en ninguno de los 2 nodos, el servicio estaba instalado, pero en ambos nodos estaba desabilitado, al habilitarlo y tratar de levantarlo enviaba error. Por supuesto al tratar de conectarse al cluster tambien enviaba error de RPC.

Habian algunos articulos muy buenos como Recover from a DAG member loss sin embargo no era el escenario, no se perdio un miembro, sino todo el cluster.

Conversando con un colega sobre las alternativas veiamos 2:

1) Guardar las bases de datos, Reinstalar con la opcion /m:RecoverServer y luego colocar las bases de datos.
2) Hacer otro DAG eliminando el actual y asociando las bases a ese nuevo DAG.

Despues de un rato viendo los pro y los contras de cada opcion nos inclinamos por la segunda, aunque no sabiamos con certeza como lo hariamos.

Antes de comenzar a trabajar con el Exchange en esa opcion intente crear un nuevo cluster con ambos nodos, seguro no lo iba a hechar a perder mas de lo que ya estaba, pero no me dejaba agregarlos por que decia que ya pertenecian a un cluster, asi que hice limpieza ejecutando el comando cluster node /force. Despues del comando intente crear el cluster con otro nombre y me dejo, lo elimine y volvi al problema.

Se crea el nuevo DAG y no podemos elegir ningun server para agregar, ya que estan asociados al otro DAG. Intente sacar un nodo y envia el error indicando problema de comunicacion con el servicio de cluster, sin embargo el mismo error me recomendaba una solucion, usar el parametro -ConfigurationOnly, al buscar informacion sobre el parametro me di cuenta que lo que hacia era cambiar la configuracion pero sin intentar conectarse al servicio de Cluster, por lo que saque del DAG antiguo el servidor que habia limpiado ya la configuracion del Cluster usando el siguiente comando PowerShell:

 Remove-DatabaseAvailabilityGroupServer –Identity DAG1 –MailboxServer NODO1 –ConfigurationOnly

Eso me permitio remover el Server del DAG y agregarlo al nuevo DAG, a continuación fui a cada una de las bases de datos revise las propiedades y guarde quedando asociadas al nuevo DAG, monto una y sube ok. Repito la operacion en el otro nodo ejecutando ambos comandos, el que limpia la configuracion de cluster del nodo2, saco del DAG antiguo el nodo2 y lo agrego al nuevo DAG.

Monto el resto de las bases de datos las cuales montaron sin problemas quedando el servicio ok, excepto una que me daba error MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-550) pero eso ya es otra historia :D

Saludos!!!

Isa

Eliminando un exchange 2010 inexistente

Siempre me tocan problemas extraños .....

En esta ocasión se trato de un disaster recovery con un recovery mas dañino que el desastre.

Con un servidor exchange inexistente que necesitaba eliminar.

Opcion 1:
- Instalar un server con el mismo nombre que el inexistente
- Instalar exchange usando Setup /m:RecoverServer
- Desinstalar Exchange en forma limpia

Esta opcion tiene sus pro y sus contras, es mas limpio, es mas seguro, es la recomendada por microsoft, pero necesito otro server el cual no tenia.

Opcion 2:

Usando ADSI Edit conectarse a la particion de configuracion, navegar hasta CN=Configuration [domain] → CN=Services → CN=Microsoft Exchange → CN=[organization] → CN=Administrative Groups → CN=Servers y eliminar el server desaparecido.

Si era un mailbox, ir a CN=Configuration [domain] → CN=Services → CN=Microsoft Exchange → CN=[organization] → CN=Administrative Groups → CN=Databases y eliminar las bases de datos relacionadas a ese servidor.

Abrir Active Directory Users and Computers y eliminar de los grupos de seguridad de Exchange (Exchange Servers y Exchange Trusted Subsystem) el server inexistentes o mejor aun, eliminar el objeto computador, validar que tampoco exista en el DNS.

Espero que esto les ayude tan bien como me ayudo a mi.

Saludos!

Isa

Azul Azul!!!!

Esa famosa pantallita que se ha hecho famosa y se asocia a Microsoft, pero según lo que me ha tocado ver, la gran mayoría de los casos se debe a otros culpables, tales como drivers o productos de terceros, pero el tema es lograr identificar quien fue el responsable de la caída inesperada y con ese dato, poder realizar las acciones necesarias para resolver la causa raíz.

Cuando ocurre la caída, el sistema guarda un DUMP de lo que estaba ocurriendo en ese momento, si es que la caída corresponde a un tema de software, en caso de un corte de energía el código de error es distinto y no queda DUMP.

Primero que nada debemos asegurarnos que estamos escribiendo un dump, si no lo tenemos difícilmente podremos realizar un análisis. Para validar esto vamos a My Computer, click con el botón derecho, Properties, en el tab Advanced, sección Startup and Recovery, click en el botón Settings. En la sección Write Debugging Information, asegurese que este seleccionado algun dump, ya sea el de Kernel o small y se encuentre el directorio donde será escrito el dump. También es buena practica que escriba un registro en el Log de Eventos, el cual será algo como lo siguiente:

Event Type:    Error
Event Source:    System Error
Event Category:    (102)
Event ID:    1003
Date:        12/20/2010
Time:        11:49:21 AM
User:        N/A
Computer:    SERVER

Description:
Error code 0000000a, parameter1 00000000, parameter2 d0000002, parameter3 00000001, parameter4 80828230.

NOTA: que para que pueda escribir el dump, es necesario que al menos una parte del archivo de paginación resida en la partición del sistema

Esto no nos dice mucho, el Error code nos ayudara a identificar si es problema de energía o de software, pero en el caso de software, nos queda el dump.

ok, ya tenemos el dump, como lo analizamos ahora??

Existe un juguetito llamado Windbg, el cual es parte de “Microsoft Debugging Tools”, el cual puede ser bajado desde Aquí. Al menos a mi me hizo también instalar el Framework .Net 4.0

Una vez instalado ejecutamos Windbg, antes de comenzar, debemos cargar los símbolos, esto es para ayudar al programa a identificar los distintos componentes que forman parte del dump. Para ello ir a File, Simbol File Path y agregar lo siguiente:

SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

Click en OK.

Ahora estamos listos para leer nuestro dump, vamos a file, Open Crash Dump, seleccionamos el archivo de dump a analizar (Memory.dmp), nos pregunta si deseamos guardar la información en un workspace, le damos Yes, nos abre una pantalla blanca con información respecto al dump recién leído, esto es algo similar a lo siguiente:

Loading Dump File [C:\Users\xxxxx\Documents\dump\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

WARNING: Whitespace at end of path element
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

Executable search path is:
Windows Server 2003 Kernel Version 3790 (Service Pack 2) UP Free x86 compatible
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Built by: 3790.srv03_sp2_gdr.100216-1301
Machine Name:
Kernel base = 0x80800000 PsLoadedModuleList = 0x8089ffa8
Debug session time: Sun Dec 19 14:41:05.155 2010 (UTC - 3:00)
System Uptime: 2 days 23:37:22.861
Loading Kernel Symbols
...............................................................
...............................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 7ffd500c).  Type ".hh dbgerr001" for details
Loading unloaded module list
...
*********************************************
*                                                                             *
*                        Bugcheck Analysis                             *
*                                                                             *
*********************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {0, d0000002, 1, 80828230}

*** ERROR: Module load completed but symbols could not be loaded for fortimon2.sys
Probably caused by : fortimon2.sys ( fortimon2+4295 )

Followup: MachineOwner
---------

En BugCheck tenemos el error code entregado en el log de eventos y sus parámetros, y en Probably caused by: tenemos al sospechoso de la caída. Si queremos obtener mas detalles del problemas ejecutamos el siguiente comando en esa consola:

!analyze

**********************************************
*                                                                                        *
*                        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: 00000000, memory referenced
Arg2: d0000002, IRQL
Arg3: 00000001, bitfield :
    bit 0 : value 0 = read operation, 1 = write operation
    bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 80828230, address which referenced memory

Debugging Details:
------------------
WRITE_ADDRESS:  00000000

CURRENT_IRQL:  2

FAULTING_IP:
nt!KeWaitForMultipleObjects+280
80828230 8902            mov     dword ptr [edx],eax

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  cidaemon.exe

TRAP_FRAME:  b8b00814 -- (.trap 0xffffffffb8b00814)
ErrCode = 00000002
eax=8a9c75b0 ebx=00000003 ecx=8721a3dc edx=00000000 esi=8a9c7508 edi=8a9c7580
eip=80828230 esp=b8b00888 ebp=b8b008b4 iopl=0         nv up ei ng nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010282
nt!KeWaitForMultipleObjects+0x280:
80828230 8902            mov     dword ptr [edx],eax  ds:0023:00000000=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from 80828230 to 80886ad1

STACK_TEXT: 
b8b00814 80828230 badb0d00 00000000 f760f69c nt!KiTrap0E+0x2a1
b8b008b4 f760b295 00000003 b8b008e8 00000001 nt!KeWaitForMultipleObjects+0x280
WARNING: Stack unwind information not available. Following frames may be wrong.
b8b008fc f76084c0 8b1a55f0 810443e2 e404c298 fortimon2+0x4295
b8b00950 f723bb73 88ce4a14 00b00974 8a9b7720 fortimon2+0x14c0
b8b009b8 f723dfc2 00ce49b8 00000000 88ce49b8 fltmgr!FltpPerformPostCallbacks+0x1c5
b8b009cc f723e4f1 88ce49b8 87e5b008 b8b00a0c fltmgr!FltpProcessIoCompletion+0x10
b8b009dc f723eb83 8ae64c80 87e5b008 88ce49b8 fltmgr!FltpPassThroughCompletion+0x89
b8b00a0c f724c5de b8b00a2c 00000000 00000000 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x269
b8b00a48 8081d5c3 8ae64c80 87e5b008 87e5b008 fltmgr!FltpCreate+0x26a
b8b00a5c 808f100b b8b00c04 8b139de8 00000000 nt!IofCallDriver+0x45
b8b00b44 8092f806 8b139e00 00000000 848ec4b0 nt!IopParseDevice+0xa35
b8b00bc4 8092b946 00000000 b8b00c04 00000040 nt!ObpLookupObjectName+0x5b0
b8b00c18 808e2ed7 00000000 00000000 79654b01 nt!ObOpenObjectByName+0xea
b8b00c94 808e4171 0007dda8 00120089 0007dd6c nt!IopCreateFile+0x447
b8b00cf0 808e6c00 0007dda8 00120089 0007dd6c nt!IoCreateFile+0xa3
b8b00d30 80883948 0007dda8 00120089 0007dd6c nt!NtCreateFile+0x30
b8b00d30 7c82860c 0007dda8 00120089 0007dd6c nt!KiFastCallEntry+0xf8
0007dd9c 00000000 00000000 00000000 00000000 0x7c82860c

STACK_COMMAND:  kb

FOLLOWUP_IP:
fortimon2+4295
f760b295 2bc7            sub     eax,edi

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  fortimon2+4295

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: fortimon2

IMAGE_NAME:  fortimon2.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4be9ce76

FAILURE_BUCKET_ID:  0xA_fortimon2+4295

BUCKET_ID:  0xA_fortimon2+4295

Followup: MachineOwner
---------

Con esto ya podemos ver cual fue la causa y el modulo que la provoco, en nuestro caso fue un acceso a una dirección de memoria que no correspondía, el detalle se puede observar en el stack text y el resto de la información.

Espero que les sirva como me sirvió a mi.

Saludos!!

Isa

Problemas de Memoria 2

Aun existen muchas máquinas que están trabajando con 32 bits, ya vimos en artículos anteriores el como optimizar el uso de memoria en estas versiones para servidores de Bases de Datos (SQL Server y Exchange) a través del uso de los parámetros /3GB y /PAE en el archivo boot.ini

 

Parámetro /PAE

Este parámetro lo que hace es permitir al sistema operativo reconocer la memoria por sobre los 4GB de RAM, a continuación una tabla de las versiones de sistema operativo y la cantidad de RAM soportada.

Windows y PAE

Versión de Windows	Soporte
Windows 2000 Profesional Windows XP	AWE API y 4GB de RAM Física
Windows XP SP2 y Posterior	AWE API y 4GB de Espacio de Direccionamiento Físico
Windows 2000 Server Windows Server 2003, Standard Edition	AWE API y 4GB de RAM Física
Windows Server 2003 SP1, Standard Edition	AWE API y 4GB de Espacio de Direccionamiento Físico
Windows Server 2003, Enterprise Edition	8 procesadores y 32GB de RAM
Windows Server 2003 SP1, Enterprise Edition	8 procesadores y 64GB de RAM
Windows 2000 Advanced Server	8 procesadores y 8GB de RAM
Windows 2000 Datacenter Server	32 Procesadores y 32GB de RAM
Windows Server 2003, Datacenter Edition	32 Procesadores y 64GB de RAM
Windows Server 2003 SP1, Datacenter Edition	32 Procesadores y 128GB de RAM

Fuente: http://www.microsoft.com/whdc/system/platform/server/PAE/pae_os.mspx

 

Parámetro /3GB

En circunstancias típicas y para cada proceso se asignan 2 GB de espacio de direcciones virtuales para el proceso de modo de usuario y se asignan otros 2 GB de espacio de direcciones virtuales para el sistema operativo. Cuando utiliza el modificador /3GB en Windows Server 2003, se asignan 3 GB de espacio de direcciones virtuales para el proceso de modo de usuario y sólo se asigna 1 GB de espacio de direcciones virtuales para el sistema operativo.

Este parámetro debe usarse con cuidado, ya que al cambiar la forma de direccionar la memoria puede obtenerse un efecto inverso al que se espera, en servidores por ejemplo que tienen el rol de Active Directory, Terminal Server (Remote Desktop) o Application Server los cuales hacen uso de memoria kernel, se ven estrangulados y su capacidad de direccionamiento disminuye, en Servidores como Exchange o SQL Server se puede apreciar su beneficio.

El problema.

Se tenían servidores con distintos roles los cuales necesitaban ser actualizados de 4GB a 32GB de RAM, eran 2 grupos de servidores, los primeros, Application servers los cuales trabajaban con IIS y los otros, Cluster SQL Server 2005.

Al realizarse el upgrade de memoria física, los servidores de Aplicación no tuvieron problemas, sin embargo los servidores de SQL Server comenzaron con un comportamiento extraño.

No se observaron errores en el log de eventos que nos indicara algún problema o la causa del problema, si aparecía un error pero al parecer era la consecuencia, este error es el Event ID 1053

Revisando mas, se observa que las tarjetas de red no presentan trafico, bytes enviados o recibidos estaban en cero.

Nada que nos indicara que podría estar ocurriendo y menos como resolverlo. El único cambio que se había realizado era agregar la memoria al servidor. Se vuelve atrás.

Se programa nuevamente la actividad pero esta vez se realiza una actualización completa del sistema operativo y los drivers correspondientes al hardware, muchos de los problemas se resuelven de esta forma, un sistema operativo actualizado tiene menor probabilidad de tener problemas relacionados con issues conocidos y con parches liberados.

Nuevamente se realiza la actualización y presenta el mismo efecto.

Que configuraciones relacionadas con la memoria tenemos en el servidor?? Pues /PAE y /3GB en el archivo boot.ini

Vamos a la configuración de booteo y duplicamos la línea donde están estos parámetros cambiándole a una de ellas la descripción y sacándole ambos.

Se reinicia el servidor y se valida la configuración de memoria. Solo reconoce 3.4Gb de los 32Gb.

Se repone el parámetro /PAE en archivo boot.ini, este parámetro esta presente en las maquinas de aplicación.

Se reinicia el servidor y se valida configuración de memoria, reconoce los 32Gb y los servicios funcionan bien.

El culpable era el parámetro /3GB, revisemos el siguiente articulo donde se explica con mas detalle que es 4GT y como funciona.

http://technet.microsoft.com/en-us/library/cc786709(WS.10).aspx

Quiero destacar de acá las siguientes líneas que describen nuestro escenario:

4GT should not be used if either of the following is true:

• Greater than 16 GB of physical memory are available and PAE X86 is enabled on the server.

Nuestra situación era exactamente esa, mas de 16Gb y PAE habilitado.

Saludos!

Isa

pd: No olvidar cambiar los tamaños en el archivo de paginación cuando se realicen aumentos de memoria!!!!!