Infv5 Jasas Rac Systemtest v220

Oficina Tcnica para la Gestin y Supervisin de
Servicios TIC
Subdireccin de Tecnologas de la Informacin
TESTING DE SISTEMAS
PARA ENTORNOS ORACLE
REAL APPLICATION
CLUSTER
Referencia documento:
InfV5_JASAS_SystemTest_Oracle_RAC_V220.doc
Fecha: 14 de abril de 2011
Versin: 2.2.
InfV5_JASAS_RAC_SystemTest_V220.doc
Ver. 2.2.
Registro de Cambios
Fecha Autor Versin Notas
14 de April de 2011 Jonathan Ortiz 2.2. Versin inicial
Revisiones
Nombre Role
Emilio Nestal Advanced Services Engineer
Distribucin
Copia Nombre Empresa
1 Subdireccin de Tecnologas de la Servicio Andaluz de Salud, Junta de

Informacin Andaluca
2 Servicio de Coordinacin de Consejera de Innovacin, Junta de
Informtica de la Consejera de Andaluca
Innovacin
Certificado ISO-9002 Pg. 2 / 3

N: 20845/G
Ver. 2.2.
ndice de Contenidos
CONTROL DE CAMBIOS ........................................................................................................................ 4

INTRODUCCIN ................................................................................................................................... 5
OBJETIVOS DE ESTE DOCUMENTO .......................................................................................................... 6
TEST DE RED DEL SISTEMA ................................................................................................................... 7
PLANING PARA LOS TESTS DEL SISTEMA .............................................................................................. 11
Test de Stress del sistema/Simulacin de un entorno de produccin ............................................. 11
Test de fallos inducidos .................................................................................................................. 12
Test de funcionalidad de componentes ........................................................................................... 12
DESCRIPCIN DE LOS TESTS ................................................................................................................ 14
Testing del Sistema: Escenarios de paradas .................................................................................. 15
Testing del Sistema: Fallos en los procesos del Clusterware ........................................................ 22
Test de componentes: Tools de diagnostico ................................................................................... 23
CONCLUSIONES Y RECOMENDACIONES ................................................................................................. 1

N: 20845/G
Ver. 2.2.
Control de cambios
Cambio Descripcin Pgina
Se aaden
Versin los requisitos
Inicial de parametrizacin de sistemas
del documento

N: 20845/G
Ver. 2.2.
Introduccin
Este documento recoge una serie de pruebas de Test comentadas por Oracle Soporte y
planteadas como buenas prcticas de sistemas para administradores que hagan uso de
Oracle RDBMS 10gR2 y 11g y Oracle RDBMS 10gR2 y 11g Real Application Cluster (RAC).
Este conjunto de pruebas engloba a varias fases de vida de Oracle RAC, desde pruebas
antes de la instalacin del software, pruebas de validacin de la instalacin y pruebas de
simulacin de produccin. Junto con ello se recogen un conjunto de pruebas de perdidas
de servicio de los diferentes componentes que forman parte de Oracle RAC.
Estas recomendaciones estn encaminadas a minimizar los posibles problemas de

configuracin y rendimiento en sistemas de cualquier tamao y en la gran mayora de los
casos se basan en la experiencia de cosas reales gestionados por Oracle Soporte.
Finalmente, este documento tambin recoge una serie de conceptos de componentes,

mdulos y tecnologas relacionadas con Oracle RDBMS 10gR2 y 11gR1 y Oracle RDBMS
11gR1 RAC, que a juicio de Oracle Soporte, deberan tenerse claros para asegurar la
aplicacin de las recomendaciones recogidas en este documento, y de manera general,
entender los productos Oracle RDBMS 10gR2 y 11g y Oracle RDBMS 10gR2 y 11g RAC sobre
los que se sostengan los sistemas y aplicaciones.

N: 20845/G
Ver. 2.2.
Objetivos de este documento

Antes de que una nueva mquina/cluster entre en funcionamiento en produccin, es
importante que se pruebe el sistema en profundidad para verificar que el comportamiento
ser el esperado. Tambin es recomendable el testeo cuando se introducen cambios en el
sistema, ya sean grandes o pequeos.
El objetivo de este documento es doble. En primer lugar, proporcionar una gua de pruebas
para testear las respuestas de un entorno activo-activo con Oracle Real Application Cluster
11gR1, antes de pasar a produccin, entre lo que se destaca:
Verificacin de la red que soportara el Clusterware de Oracle RAC.
Verificar que el sistema ha sido correctamente instalado y configurado.
Asegurar que el sistema sea capaz de alcanzar los objetivos esperados,

particularmente de disponibilidad y rendimiento.
En segundo lugar, este documento puede servir como plantilla para realizar dichas
pruebas y anotar los resultados obtenidos, verificando as la respuesta del sistema ante
posibles fallos.
La configuracin del sistema y procedimientos operacionales, deben tambin ser testeados

para asegurar que los fallos de sus componentes y otros problemas pueden ser tratados de
la manera ms eficiente y con el menor impacto posible.
El propsito de este test es probar la robustez del sistema ante los distintos fallos.
Se recomienda que las pruebas sean ejecutadas bajo una carga de trabajo que simule al de
un entorno de produccin real, y en exclusividad de otras pruebas para poder medir
eficientemente los resultados obtenidos.

N: 20845/G
Ver. 2.2.
Test de Red del Sistema

Debido a la importancia que tiene la red en un entorno de RAC se ha introducido este
apartado donde se intenta recoger las consideraciones a nivel de red en un sistema que
soporta RAC.
Un error comn acerca de la red privada (interconexin del clster) que utiliza un sistema
RAC es que se utiliza solamente como mecanismo de heartbeat. Cuando una base de datos
RAC se ejecuta en clster que utiliza la interconexin del clster para mantener la
coherencia de cach y realizar operaciones de cach de fusin. En trminos de red puro,
bloques enteros de base de datos (definido por el tamao de bloque de base de datos, 8k
por defecto) multiplicado por el nmero de bloques accesibles en una sola lectura (definido
por la base de datos como multi-block read count, por defecto 16) pueden potencialmente (
y es probable que) ser transferido en cualquier momento a travs de la red de
interconexin.
Por ejemplo, en un clster de 2 nodos que un usuario realiza una consulta que requiere un
escaneo completo de una tabla Tabla_A en la instancia 1. Los bloques de base de datos para
cumplir con esta consulta no estn en la cach del buffer en la instancia 1, pero si estn en
la cach del bfer en la instancia 2. Dado que es menos costoso a partir de una perspectiva
de rendimiento realizar la lectura desde la red que desde E/S, los bloques de la base de
datos se extraen de la cache de la instancia 2 para cumplir con la solicitud de consulta. En
este caso, estos bloques se transfieren en lecturas de 128 KB (suponiendo que el tamao de
bloque de base de datos de 8 KB y 16 multi-block read count) de tamao.
Este ejemplo pone de manifiesto que es de vital importancia el tener configurado la red de
interconexin de manera ptima.
Para que la red privada pueda soportar el trfico de red generado por un cluster RAC,
todos los elementos que intervienen en la red deben estar funcionando en armona para
permitir a la red para llevar a cabo sin errores y en su espera que los niveles ptimos de
Gigabit Ethernet. Lo ideal sera que este control del rendimiento y la estabilidad se llevarn
a cabo antes de instalar el software del RAC para reducir al mnimo la necesidad y la
complejidad de los cambios de configuracin una vez que el software de RAC est
instalado.
Hay muchas utilidades que se pueden encontrar en Internet para poner a prueba el
rendimiento de la red y tiempos de respuesta. Este documento se centrar en una utilidad
llamada Netperf. Netperf es gratuito y puede ser compilado en prcticamente cualquier
plataforma.
Netperf consta de 2 componentes, un componente del lado del cliente que proporciona el
motor de las pruebas que se llevarn a cabo y otro componente del lado del servidor que
simplemente de escucha y responde a las peticiones formuladas por el componente cliente.
Las pruebas que son posibles con netperf son:
TCP Stream Performance (this is the default test)

N: 20845/G
Ver. 2.2.
UDP Stream Performance
DLPI Connection Oriented Stream Performance
DLPI Connectionless Stream Performance
UNIX Domain Stream Socket Performance
UNIX Domain Datagram Socket Performance
Fore ATM API Stream Performance
TCP Request/Response Performance
UDP Request/Response Performance
DLPI Connection Oriented Request/Response Performance
DLPI Connectionless Request/Response Performance
UNIX Domain Stream Request/Response Performance
UNIX Domain Datagram Request/Response Performance
Fore ATM API Stream Request/Response Performance
Los detalles sobre cada una de las pruebas disponibles enumeradas anteriormente se
puede encontrar en el manual del usuario netperf que est situado en el sitio web netperf:
http://www.netperf.org/netperf/NetperfPage.html
El cdigo fuente de Netperf est disponible para su descarga en el sitio web netperf.org.
Suponiendo una configuracin por defecto para Oracle RAC utilizando TCP para la
comunicacin de clster y UDP para el trfico de RDBMS, se recomienda probar el ancho
de banda y la latnecia de solicitud /respuesta para los protocolos TCP y UDP a travs de la
interconexin privada. Las pruebas adicionales pueden incluir el rendimiento del
throughput TCP y de solicitud/respuesta sobre la interfaz pblica.

N: 20845/G
Ver. 2.2.
Grfico Netperf TCP Stream Test
La grfica anterior muestra, la media de rendimiento de throughput TCP fue 114,12 MB

por segundo. En Gigabit Ethernet el rendimiento ms alto posible es de unos 125 MB por
segundo, menos el overhead del TCP a travs de Ethernet (~ 5 - 5,5%) y la latencia del
cable (depende de la infraestructura), lo que significa que 114,12 MB por segundo est en
consonancia con lo esperado con un buen rendimiento.
Grfico Netperf TCP Request/Response Test
En la grfica anterior se muestra, la tasa de transaccin de 6.018,04 por segundo para un

mensaje de 1 byte. La divisin de un segundo por el ratio de transaccin mostrar la
latencia de ida y vuelta para cada byte que es de 167 microsegundos. De nuevo, esto est
en consonancia con la latencia de espera de Gigabit Ethernet.
Grfico Netperf UDP Stream Test
La grfica anterior muestra el promedio de throughput UDP fue 115,72 MB por segundo.
El Gigabit Ethernet el rendimiento ms alto posible es de unos 125 MB por segundo, menos
los gastos de la UDP a travs de Ethernet (~ 4,9 a 5,3%) y la latencia de red (dependiendo

N: 20845/G
Ver. 2.2.
de la infraestructura), lo que significa que 115,72 MB por segundo est en consonancia con
lo esperado de un buen rendimiento.
Grfico Netperf UDP Request/Response Test
La grfica anterior muestra, la tasa de transaccin UDP de 6.328,72 por segundo para un
mensaje de 1 byte. La divisin de un segundo por el ratio de transaccin mostrar la
latencia de ida y vuelta para cada mensaje de 1 byte de 158 microsegundos. De nuevo, esto
est en consonancia con la latencia de espera de Gigabit Ethernet.
El throughput y latencia de una red Gigabit se ven influidos por varios factores como la
velocidad del bus PCI, la latencia del switch, la longitud del cableado, etc. Dicho esto, una
red privada de interconexin implementada con las mejores best-practices (switches
redundantes y dedicados) debe alcanzar en torno al 95 % del ancho de banda anunciado
como latencia en microsegundos en el rango de 150-200 para un mensaje de 1 byte. El xito
en pruebas de la red se mide de la siguiente manera:
Los resultados de la prueba (ancho de banda y latencia) caen dentro de los

rangos esperados para Gigabit Ethernet?
Si se utiliza una configuracin tolerante a fallos redundante NIC, el fallo de un

path tiene que ser cubierto por otro path sin interrupcin del servicio
Si las interfaces de red informan de errores o prdida de paquetes durante la

pruebas.
Si hay errores o problemas que se informa a nivel de protocolo de red (netstat-s)
Hubo algn error de red reportados en cualquier log dentro de la tecnologa de

red (sistema operativo o Switch)?
Es muy recomendable investigar y corregir cualquier problema potencial antes de

comenzar la instalacin del software del RAC. Este enfoque evita tener que realizar
cambios de configuracin en el software del RAC, debido a que generan cambios de
configuracin de red, as como reducir significativamente el posible problema de una
instalacin fallida.

N: 20845/G
Ver. 2.2.
Planing para los tests del sistema

Las pruebas de testing del sistema requieren una planificacin cuidadosa para que sean
efectivas. Los objetivos de nivel de servicio para el sistema en s mismo y para la prueba
deben quedar claros y un plan detallado de las pruebas debe ser documentado. La base
para todas las pruebas es que las best-practices actuales para la configuracin del sistema
en Oracle RAC han sido llevadas a cabo antes de la prueba.
Las pruebas deben realizarse en un entorno que refleje el entorno de produccin tanto
como sea posible, lo ideal sera realizarlo en el mismo antes de la puesta en produccin. La
configuracin de software deben ser idnticas, pero por razones de coste, podra ser
necesario utilizar un configuracin de hardware reducida en algunas ocasiones. Todas las
pruebas sern realizadas durante la ejecucin de una prueba de carga de trabajo lo ms
cercana a la produccin como sea posible. Al planificar las pruebas del sistema es
sumamente importante para entender cmo la aplicacin ha sido diseada para manejar
los fallos descritos en este plan y asegurar que los resultados previstos se ajustan al nivel
de alta disponibilidad que soporta la aplicacin, as como al nivel de alta disponibilidad de
la base de datos. Oracle que permiten la tolerancia a fallos de la base de datos a nivel de
aplicacin son los siguientes:
Generar una realista carga de trabajo de aplicacin puede ser complejo y costoso, pero es el
factor ms importante para la eficacia de las pruebas. Para cada prueba individual del
plan, se requiere:
Cul es el objetivo de la prueba y cmo se relaciona este con los objetivos del
sistema en general?
Exactamente, cmo se realiza la prueba y cules son los pasos de ejecucin?
Cules son los criterios de xito o fracaso, y cules son los resultados esperados?
Cmo se medir el resultado de la prueba?
Qu herramientas se utilizarn?
Qu datos sern recogidos y cules son los ficheros de logs a revisar?
Qu procedimientos operativos son relevantes?
Test de Stress del sistema/Simulacin de un entorno de produccin

La mejor manera de garantizar que el sistema funcionar bien sin ningn tipo de
problemas es simular la carga de trabajo de produccin y las condiciones de trabajo antes
de publicarlo. Lo ideal sera que el sistema debe ser estresado en algo ms de lo que se
espera en la produccin. Adems de ejecutar la carga de trabajo de aplicacin, todos los
procedimientos operativos normales tambin deben ser examinados al mismo tiempo,
como procedimientos de ejecucin periodica. El resultado de las pruebas se debe mantener
y ser comparado con los datos reales cuando se realice la puesta en produccin. Las
operaciones normales de mantenimiento, como agregar usuarios, aadir espacio en disco,

N: 20845/G
Ver. 2.2.
la reorganizacin de tablas e ndices, copias de seguridad, el archivado de datos, etc

Tambin se deben probar.
Test de fallos inducidos

La configuracin del sistema y los procedimientos operativos deben ser evaluados para
asegurarse de que los fallos de componentes y otros problemas pueden ser tratados con la
mayor eficacia posible y con el mnimo impacto sobre la disponibilidad del sistema. Esta
seccin proporciona algunos ejemplos de las pruebas que se pueden utilizar como parte de
un plan de pruebas del sistema. La idea es poner a prueba la robustez del sistema frente a
diferentes fallos.
Esta lista slo incluye las pruebas para los componentes de RAC. Pruebas adicionales se
necesitan para otras partes del sistema pero se salen del objetivo de este documento.
En algunos escenarios de fallo podra no ser posible recuperar el sistema dentro de un

marco de tiempo aceptable y un plan de failover debe especificarse para cambiar a un
sistema alternativo o a una ubicacin alternativa. Esto tambin puede ser probado.
Test de funcionalidad de componentes

Normalmente no debera ser necesario realizar pruebas de funcionalidad adicionales para
cada componente del software en RAC. Sin embargo, para algunos componentes pueden
ser tiles realizar pruebas adicionales para asegurarse de que estn configurados
correctamente. Esta prueba tambin ayudar a los administradores de bases de datos
familiarizarse con los nuevos componentes de Oracle Rdbms 11gR1.
Cluster Infrastructure
Para simplificar las pruebas a menudo es muy til hacer algunas pruebas bsicas en la
infraestructura de clster sin el software de Oracle. Normalmente, esta prueba se llevar a
cabo despus de instalar el hardware y sistema operativo, pero antes de instalar cualquier
software de Oracle. Normalmente algunas de las pruebas que se utilizaran son las
siguientes:
Fallo de un nodo. sin el software de Oracle instalado.
Reinicio de un nodo fallido.
Reiniciar todos los nodos a la vez.
Prdida de acceso a disco.
HBA failvoer. Suponiendo que existen mltiples HBA con capacidad de failover.
Failover de la Controladora de Discos. Suponiendo que existen varios

controladores de disco con capacidad de failover.
Fallo de la NIC Pblica

N: 20845/G
Ver. 2.2.
Fallo de la NIC de Interconexin
Error de almacenamiento NAS- En el caso de un fallo de espejo completo, medir el

tiempo que la reconfiguracin de almacenamiento necesita para ser completado.
Si se utiliza un software de cluster de terceros:
Simular un fallo en la red de Interconnect
Simular una prdida de acceso a los discos de qurum

N: 20845/G
Ver. 2.2.
Descripcin de los Tests

En los siguientes apartados se describen las bateras de pruebas a realizar sobre el entorno.
Se debe tener en cuenta que estas pruebas estn orientadas tanto a entorno RAC como
single instance en activo-pasivo, por lo que se debe aplicar lo que corresponda
dependiendo del tipo de entorno que se est probando.
Los test se han clasificado en diferentes apartados atendiendo, bien a la funcionalidad que
comprueban, bien al componente que interviene.
Los apartados en los que se han clasificado los test son los siguientes:
Grupo de Test Descripcin
Testing del Sistema: Escenarios Este grupo de tests define una serie de escenarios de
de paradas desastre que determinan un tipo de test a realizar. Se
deben realizar los test que sean aplicables al entorno que
se quiere validar, ya que no siempre los escenarios que se
presentan son los que pueden ocurrir en el entorno, por
las caractersticas del propio CPD, mquinas, etc.
Testing del Sistema: Fallos en los Este grupo de test se refiere a posibles fallos en los
procesos del Clusterware procesos del Clusterware.
Test de componentes: Tools de Pruebas de que las herramientas de diagnostico se

diagnostico ejecutan correctamente

N: 20845/G
Ver. 2.2.
Testing del Sistema: Escenarios de paradas

Test ID Descripcin Procedimiento Resultados esperados Medidas Resultados
obtenidos/Notas
Test 1 Reinicio controlado del Iniciar la carga de trabajo Las instancias y otros Tiempo para la deteccin del
nodo Identificar las instancias con mayor recursos del cluster que se fallo del nodo o de la
nmero de conexiones de cliente estaban ejecutando en el instancia
Reiniciar el nodo en el que se nodo reiniciado (No Tiempo para completar la
encuentre la instancia con mayor aparecera valor para el recuperacin de la instancia.
carga campo 'Server' desde la Tiempo para restaurar la
o Para Solaris: reboot salida desde: crsctl stat res -t) actividad de los clientes al
mismo nivel (suponiendo
que los dems nodos tienen
la capacidad suficiente para
ejecutar la carga de trabajo)
Duracin de la
reconfiguracin de la base de
datos.
El xito de conmutacin de
las VIP(s)
Test 2 Fallo del nodo del OCR Iniciar la carga de trabajo Igual que en el test 1 Igual que en el test 1
Master Identificar el nodo donde se
encuentra el OCR Master con el
siguiente commando:
grep -i "OCR MASTER"
$CRS_HOME/log/<node_name>/crsd/crs
d.l*
Apagar el nodo que contiene el OCR

Master.

N: 20845/G
Ver. 2.2.

obtenidos/Notas
Test 3 Rebotar todos los nodos Realizar un reboot en todos los nodos al Todos los nodos, instancias Tiempo para que todos los
al mismo tiempo. mismo tiempo deben ser reiniciados sin recursos vuelvan a estar
Para Solaris: reboot problemas. disponibles. Chequearlo con
crsctl stat res t.
Test 4 Fallo de una instancia Iniciar la carga de trabajo Una de las otras instancias Tiempo para la deteccin del
Identificar que tienen mayor carga de realizara el instance recovery. fallo del nodo o de la
trabajo: Los servicios son movidos a instancia
Para Solaris: las instancias disponibles. Tiempo para completar la
o Obtener el PID para el proceso Las conexiones de clientes recuperacin de la instancia.
PMON: son reconectadas a las Tiempo para restaurar la
# ps ef | grep pmon intancias supervivientes.( actividad de los clientes al
o kill del proceso pmon: Dependiendo de la mismo nivel (suponiendo
# kill 9 <pmon pid> configuracin se tendr un que los dems nodos tienen
comportamiento u otro) la capacidad suficiente para
Despues de la parade, el ejecutar la carga de trabajo)
resto de instancias Duracin de la
continuaran con la carga de reconfiguracin de la base de
trabajo. datos en el failover.
Instancia fallida sera Tiempo antes de que la
reiniciada por el Clusterware instancia fallida sea
Oracle, al menos que esta reiniciada por el Clusterware
opcin este deshabilitada. de Oracle.

N: 20845/G
Ver. 2.2.

obtenidos/Notas
Test 5 Parada forzosa de una Usar un shutdown abort Una de las otras instancias Tiempo para la deteccin del
instancia realizara el instance recovery. fallo del nodo o de la
Los servicios son movidos a instancia
las instancias disponibles. Tiempo para completar la
Las conexiones de clientes recuperacin de la instancia.
son reconectadas a las Tiempo para restaurar la
intancias supervivientes.( actividad de los clientes al
Dependiendo de la mismo nivel (suponiendo
configuracin se tendr un que los dems nodos tienen
comportamiento u otro) la capacidad suficiente para
Despues de la parade, el ejecutar la carga de trabajo)
resto de instancias Duracin de la
continuaran con la carga de reconfiguracin de la base de
trabajo. datos en el failover.
La instancia fallida NO sera
reiniciada por el Clusterware
Oracle, debido a que el
usuario invoco un shutdown.
Test 6 Reinicio de una Instancia Reinicio manual de una instancia La instancia se vuelve unir al Tiempo antes de que los
cluster de RAC sin ningn servicios y la carga de trabajo
problema. es rebalanceada al resto de
Las conexiones de clients y la instancias.
carga de trabajo comienza
cargar con la instancia una
vez se encuentra disponible
de nuevo.

N: 20845/G
Ver. 2.2.

obtenidos/Notas
Test 7 Fallo mltiple de Iniciar la carga de trabajo Mismo que Test 4 Mismo que Test 4
instancias. Identificar dos instancias que tengan
la mayor carga de trabajo:
Para Solaris:
o Obtener el PID para el proceso
PMON:
# ps ef | grep pmon
o kill del proceso pmon:
# kill 9 <pmon pid>
Test 8 Fallo del Listener Para Solaris: No impacta en las sesiones Tiempo para que el
o Obtener el PID para el listener conectadas a la base de clusterware detecte el fallo
proceso: datos. del listener y lo reinicie.
# ps ef | grep tnslsnr Nuevas conexiones son
o Kill el listener: redirigidas al listener de otro
# kill 9 <listener pid> nodo ( depende de la
configuracin del cliente )
La base de datos local no
recibira nuevas conexiones.

N: 20845/G
Ver. 2.2.

obtenidos/Notas
Test 9 Fallo de la Red Publica. Desconectar todos los cables de red Chequear con crsctl stat res Tiempo para detector el fallo
de la red publica. t de red y realojar los recursos.
o El ora.*.network y los
Nota: No se recomienda usar ifconfig recursos de listener son
para parar la interfaz de red. parados en ese nodo.
o La VIP realizara failover
para el nodo
superviviente.
La instancia de base de datos
permanecera arrancada pero
sera desregistrada de los
remote listeners.
Los servicios de base dedatos
realizaran failover a los
nodos supervivientes.
Test 10 Fallo de la Red Publica Asumiendo que interfaces El trafico de red debera Tiempo para realizar el
duplicadas son configuradas para la realizar failover sobre la otra failover sobre la otra tarjeta
redundancia ( bonding, teaming, etc) interfaz sin impactar en los de red.Con bonding
Desconectar todos los cables de red recursos del clusterware. /teaming configurado este
de una de las interfaces de la red debera ser menor de 100ms.
publica.
Nota: No se recomienda usar ifconfig

para parar la interfaz de red.

N: 20845/G
Ver. 2.2.

obtenidos/Notas
Test 11 Fallo de la red de Desconectar todos los cables de red CSSD detectara la situacin Tiempo para detector un
Interconnect de la red de interconnect. de split-brain y ejecutara una split brain e iniciar el
de las siguientes opciones: desacople de las instancias.
Nota: No se recomienda usar ifconfig o En uno de los dos nodos Ver las medidas del Tes de
para parar la interfaz de red. del cluster ( el que arranco fallo del nodo.
en primer lugar
sobrevivira )
Reviesar los siguientes logs:
$CRS_HOME/log/<nodename>/cssd/c
ssd.log
$CRS_HOME/log/<nodename>/alert<
nodename>.log
Test 12 Fallo de la red de Asumiendo que interfaces El trafico de red debera Tiempo para realizar el
Interconnect duplicadas son configuradas para la realizar failover sobre la otra failover sobre la otra tarjeta
redundancia de la red de interfaz sin impactar en los de red.Con bonding
interconnect ( bonding, teaming, etc) recursos del clusterware. /teaming configurado este
Desconectar todos los cables de una debera ser menor de 100ms.
de las interfaces de la red de
interconnect.
Nota: No se recomienda usar ifconfig

para parar la interfaz de red.
Test 13 Fallo del Switch de En una red con configuracin de El trafico de red debera Tiempo para realizar el
Interconnect switches redundandes, apagar un realizar failover sobre el otro failover sobre la otra tarjeta
(En configuraciones con switch. switch sin impactar en los de red.Con bonding
redundancia de recursos del clusterware. /teaming configurado este
Switches) debera ser menor de 100ms.

N: 20845/G
Ver. 2.2.

obtenidos/Notas
Test 14 Perdida de acceso desde Desconectar el cable de conexin al Si multi-pathing esta Monitorizar el estado de las
un nodo al sistema de almacenamiento externo (SCSI, FC configurado, el multi- instancias de base de datos
discos de un Single Path or LAN cable) desde el nodo al pathing deberia bajo la carga para asegurar
(OCR, Voting Disk o sistema de discos. proporcionar transparencia que no ocurre ninguna
Datafiles) al fallo interrupcin del servicio.
No impactara en las Path failover debera ser
instancias de base de datos. visible a nivel de logs del
sistema operativo.
Test 15 Aadir un nodo al RAC Seguir el procedimiento indicado en El Nuevo nodo es aadido Tiempo en aadir el Nuevo
Oracle Real Application Clusters satisfactoriamente al cluster. nodo al cluster
Administration and Deployment La nueva instancia de la base Tiempo en que empieza a
Guide 11g Release 1 Capitulo 8 de datos comenzara a dar dar servicio a nuevas
para eliminar un nodo del cluster. servicio y aceptar peticiones conexiones
Verificar que has aadido el nodo de clients.
del cluster correctamente:
o cluvfy comp crs -n all
Test 16 Eliminar un nodo del Seguir el procedimiento indicado en Las conexiones a la base de Tiempo en eliminar el nodo
RAC Oracle Real Application Clusters datos que se encuentran en la del cluster.
Administration and Deployment instancia alojada en ese nodo
Guide 11g Release 1 Capitulo 8 son repartidas por failover al
para eliminar un nodo del cluster. resto de instancias
Verificar que has eliminado el nodo supervivientes.
del cluster correctamente: El nodo es eliminado del
o cluvfy comp crs -n all cluster de forma correcta.

N: 20845/G
Ver. 2.2.
Testing del Sistema: Fallos en los procesos del Clusterware

obtenidos/Notas
Test 17 Fallo del proceso: Para El proceso CRSD fallara es Tiempo para reiniciar el
CRSD Solaris: detectado y sera reiniciado proceso CRSD
$CRS_HOME/log/<nodename>/crsd/crsd.l
o Obtener el PID para el og
proceso CRSD:
# ps ef | grep crsd
o Matar al proceso CRSD:
# kill 9 <crsd pid>
Test 18 Fallo del proceso: Para El proceso EVMD fallara es Tiempo para reiniciar el
EVMD Solaris: detectado y sera reiniciado: proceso EVMD
$CRS_HOME/log/<nodename>/evmd/evmd.l
o Obtener el PID para el og
proceso EVMD:
# ps ef | grep evmd
o Matar al proceso EVMD:
# kill 9 <evmd pid>
Test 19 Fallo del proceso: Para El nodo sera reiniciado. Tiempo en el que se detecta
CSSD Solaris: Se realizara una reconfiguracin el fallo y la reconfiguracin
o Obtener el PID para el del Cluster. de los nodos supervivientes.
proceso CSSD: Tiempo en el que el nodo
# ps ef | grep cssd que falla vuelve a estar
o Matar al proceso CSSD: online.
# kill 9 <cssd pid>

N: 20845/G
Ver. 2.2.
Test de componentes: Tools de diagnostico

obtenidos/Notas
Test 20 Procedimientos de Iniciar la carga de trabajo Las herramientas de diagnostic se

diagnostico Ejecutar los procedimientos para han ejecutado correctamente.
recopilar la informacin de El tiempo de ejecucin de estas
diagnostic desde las herramientas es acceptable.
herramientas: hanganalyze,
racdiag.sql

N: 20845/G
Conclusiones y Recomendaciones
La batera de test propuestos puede no aplicar a un sistema concreto, o haberse
probado ya con anterioridad, por lo que se deben definir las pruebas de verificacin
de un sistema en conjunto entre los DBAs y Sistemas de forma que los escenarios
que se prueben se correspondan con la realidad de los entornos.
En el caso de un sistema en cluster, en el que las bases de datos no estn en RAC

algunas de las pruebas no tienen sentido, ya que se asume que hay 1 o varias bases
de datos en RAC en el cluster.
Tambin algunas de las pruebas no tienen sentido, ya que asumen que se puede
aadir y quitar un nodo, lo que depende de los recursos que se dispongan.

Infv5 Jasas Rac Systemtest v220

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Infv5 Jasas Rac Systemtest v220

Uploaded by

Copyright:

Available Formats

Oficina Tcnica para la Gestin y Supervisin de

Fecha Autor Versin Notas

14 de April de 2011 Jonathan Ortiz 2.2. Versin inicial

Emilio Nestal Advanced Services Engineer

Copia Nombre Empresa

1 Subdireccin de Tecnologas de la Servicio Andaluz de Salud, Junta de

Certificado ISO-9002 Pg. 2 / 3

CONTROL DE CAMBIOS ........................................................................................................................ 4

Certificado ISO-9002 Pg. 3 / 3

Certificado ISO-9002 Pg. 4 / 4

Estas recomendaciones estn encaminadas a minimizar los posibles problemas de

Finalmente, este documento tambin recoge una serie de conceptos de componentes,

Certificado ISO-9002 Pg. 5 / 5

Objetivos de este documento

Verificacin de la red que soportara el Clusterware de Oracle RAC.

Verificar que el sistema ha sido correctamente instalado y configurado.

Asegurar que el sistema sea capaz de alcanzar los objetivos esperados,

La configuracin del sistema y procedimientos operacionales, deben tambin ser testeados

Certificado ISO-9002 Pg. 6 / 6

Test de Red del Sistema

TCP Stream Performance (this is the default test)

Certificado ISO-9002 Pg. 7 / 7

UDP Stream Performance

DLPI Connection Oriented Stream Performance

DLPI Connectionless Stream Performance

UNIX Domain Stream Socket Performance

UNIX Domain Datagram Socket Performance

Fore ATM API Stream Performance

TCP Request/Response Performance

UDP Request/Response Performance

DLPI Connection Oriented Request/Response Performance

DLPI Connectionless Request/Response Performance

UNIX Domain Stream Request/Response Performance

UNIX Domain Datagram Request/Response Performance

Fore ATM API Stream Request/Response Performance

Certificado ISO-9002 Pg. 8 / 8

Grfico Netperf TCP Stream Test

La grfica anterior muestra, la media de rendimiento de throughput TCP fue 114,12 MB

Grfico Netperf TCP Request/Response Test

En la grfica anterior se muestra, la tasa de transaccin de 6.018,04 por segundo para un

Grfico Netperf UDP Stream Test

Certificado ISO-9002 Pg. 9 / 9

Grfico Netperf UDP Request/Response Test

Los resultados de la prueba (ancho de banda y latencia) caen dentro de los

Si se utiliza una configuracin tolerante a fallos redundante NIC, el fallo de un

Si las interfaces de red informan de errores o prdida de paquetes durante la

Si hay errores o problemas que se informa a nivel de protocolo de red (netstat-s)

Hubo algn error de red reportados en cualquier log dentro de la tecnologa de

Es muy recomendable investigar y corregir cualquier problema potencial antes de

Certificado ISO-9002 Pg. 10 / 10

Planing para los tests del sistema

Exactamente, cmo se realiza la prueba y cules son los pasos de ejecucin?

Cmo se medir el resultado de la prueba?

Qu datos sern recogidos y cules son los ficheros de logs a revisar?

Qu procedimientos operativos son relevantes?

Test de Stress del sistema/Simulacin de un entorno de produccin

Certificado ISO-9002 Pg. 11 / 11

la reorganizacin de tablas e ndices, copias de seguridad, el archivado de datos, etc

Test de fallos inducidos

En algunos escenarios de fallo podra no ser posible recuperar el sistema dentro de un

Test de funcionalidad de componentes

Fallo de un nodo. sin el software de Oracle instalado.

Reinicio de un nodo fallido.

Reiniciar todos los nodos a la vez.