WebSphere Application Server Infraestructura

4.1 Infraestructura de planificacin

Esta seccin ofrece una visin general de las fases tpicas que tienen que pasar durante un proyecto. Incluye cmo reunir los requisitos y la forma de aplicar estos requisitos a un proyecto de WebSphere Application Server. Normalmente, un nuevo proyecto se inicia con slo un concepto. Poco se sabe acerca de los detalles especficos de aplicacin, en especial su relacin con la infraestructura. Su equipo de desarrollo y el equipo de infraestructura deben trabajar en estrecha colaboracin para atender a las necesidades del entorno de aplicacin general. Reunir a un equipo grande de personas puede crear un ambiente que ayuda a perfeccionar los requisitos del entorno. Sin embargo, si fuera de foco, un equipo grande puede vagar sin rumbo y crear ms confusin que los problemas resueltos. Por este motivo, debe tener en cuenta el tamao de los requisitos de recopilacin de equipo y tratar de mantener las reuniones lo ms centrado posible. Proporcionar modelos de documentos para ser completados por los promotores, los propietarios de negocios de aplicaciones, y el equipo de experiencia del usuariocategoras:. Trate de obtener informacin que cae en las siguientes Requisitos funcionales Los requisitos funcionales son generalmente determinados por las empresas en el uso de la aplicacin y afines funciones. Los requerimientos no funcionales Los requerimientos no funcionales describen las propiedades de la arquitectura subyacente y la infraestructura, tales como la fiabilidad, escalabilidad, disponibilidad y seguridad. Los requisitos de capacidad Necesidades de capacidad incluyen las estimaciones de trfico, patrones de trfico y el tamao de la audiencia esperada. reunin Requisitos es un proceso iterativo. Asegrese de que sus planes son lo suficientemente flexibles para hacer frente a los futuros cambios en los requerimientos Siempre tenga en cuenta que los planes pueden afectar otras partes del proyecto. Para apoyar esto, asegrese de que las dependencias y los datos de flujos-, si la aplicacin o infraestructura relacionada, estn claramente documentados. Con esta lista de requisitos, usted puede comenzar a crear el primer borrador de su diseo. Target desarrollo de los diseos siguientes: Aplicacin de diseo para crear el diseo de su aplicacin, use sus requerimientos funcionales y no funcionales para crear directrices para los desarrolladores de la aplicacin sobre la forma en que su aplicacin est construidatu. Diseo Implementacin Este diseo define la infraestructura de implementacin de destino en que aplicacin se implementa. La versin final de este diseo de la aplicacin tendr los detalles sobre el hardware, los procesadores y el software que est instalado. Sin embargo, no es necesario empezar con todos estos detalles. En un principio, el diseo de su aplicacin se limita a enumerar los requisitos de componentes, como una base de datos, un conjunto de servidores de aplicaciones, un conjunto de servidores Web, y todo lo dems componentes se definen en la fase de requisitos. Con estos dos diseos de proyectos, usted puede comenzar el proceso de la formulacin de cargos de los servidores, los requisitos de red y los otros artculos relacionados con la infraestructura. Se describe en este 4.3, "Dimensionamiento de la infraestructura" en la pgina 106. En algunos casos, puede ser apropiado

realizar pruebas de referencia. Hay muchas maneras de realizar las pruebas de evaluacin comparativa, y en 4.4, "Benchmarking" en la pgina 107, se describen algunos de estos mtodos. El ltimo paso en cada despliegue es para ajustar el sistema y medir si se puede manejar la carga proyectada que tu no -funcionales requisitos especificados. Para ms detalles sobre la forma de planificar las pruebas de carga, vea 4.5, "Ajuste del rendimiento" en la pgina 108.

4.2 Consideraciones de diseo

En las secciones siguientes se describen algunos puntos a considerar cuando se disea un despliegue de WebSphere Application Server. Que lo ms probable es que el impacto del diseo de manera significativa. Vamos a hablar con ms detalle sobre: "Escalabilidad" en la pgina 96 "Caching" en la pgina 98 "Alta disponibilidad" en la pgina 99 "equilibrio de carga y conmutacin por error-" en la pgina 100 "Recuperacin de desastres" en la pgina 101 "Seguridad" en la pgina 102 "despliegue de aplicaciones" en la pgina 104 "Servicability" en la pgina 105

4.2.1
EscalabilidadLa escalabilidad, tal como se utiliza en este libro, significa la capacidad del medio ambiente para crecer como crece la carga de la infraestructura. El diseo de su infraestructura para ser escalable por lo tanto, significa disear su infraestructura con la capacidad de crecer. Escalabilidad depende de muchos factores diferentes, tales como hardware, sistema operativo, middleware, y as sucesivamente. Por ejemplo, los sistemas z / OS generalmente escalan mejor para las transacciones comerciales de otras plataformas. Comprender la escalabilidad de los componentes de su infraestructura de WebSphere Application Server y la aplicacin de tcnicas apropiadas de escala puede mejorar la disponibilidad y el rendimiento. Tcnicas de escalamiento son especialmente tiles en las arquitecturas de varios niveles cuando se quiere evaluar los componentes asociados con balanceadores de carga de IP, como por ejemplo los siguientes componentes: despachadores o los servidores de de la banda bordepresentacin servidores web servidores de aplicaciones de datos servidores de transacciones servidores lgicos particiones (LPAR) Utilice los siguientes pasos para clasificar su sitio web e identificar las tcnicas de escalamiento que son aplicables a su entorno: 1. Comprender el entorno de aplicaciones. Las aplicaciones son clave para la escalabilidad de la infraestructura. Se debe asegurar que las aplicaciones estn diseadas para el escalado. Es importante entender el flujo de los componentes y los volmenes de trfico asociados con las aplicaciones existentes y para evaluar la naturaleza de las nuevas aplicaciones. Es esencial para comprender cada componente individual y el sistema se utiliza en el flujo de la transaccin. Evaluar como escalamiento se puede aplicar para cada uno de estos componentes y aplicaciones. Los diferentes tipos de aplicaciones representan diferentes patrones de carga de trabajo. Por ejemplo, las aplicaciones de banca en lnea puede experimentar la mayor carga de trabajo en el servidor de base de datos, mientras que otras aplicaciones pueden experimentar la mayor carga de trabajo en el servidor de aplicaciones. 2. Clasifique su carga de trabajo.

Conocer el patrn de carga de trabajo para un sitio determina dnde centrar los esfuerzos de escalabilidad y que las tcnicas de escalamiento que debe aplicar. Por ejemplo, un cliente de autoservicio sitio, como por ejemplo un banco en lnea, tiene que centrarse en el rendimiento de la transaccin y la escalabilidad de las bases de datos que contienen la informacin del cliente que se utiliza en las sesiones. Estas consideraciones no tpicamente sera significativo para una publicacin / suscripcin de sitio, donde un usuario se registra para los datos que se enviarn a ellos, por lo general a travs de un mensaje de correo electrnicoPublicar. de los sitios Web con patrones similares de carga de trabajo se pueden clasificar en los siguientes tipos de sitios: - / subscribe - Compras Online - Cliente de autoservicio online - comercial - Negocio a negocio 3. Determinar los componentes ms afectados. Este paso implica el mapeo de las caractersticas del emplazamiento ms importantes para cada componente. Desde un punto de vista escalabilidad, los componentes clave de la infraestructura son los balanceadores de carga, los servidores de aplicaciones, servicios de seguridad, servidores de transacciones y datos, y la red. En primer lugar se centran en aquellos componentes que estn ms utilizadas por las operaciones clave de sus aplicaciones. 4. Seleccione las tcnicas de escalamiento para aplicar. Cuando la recopilacin de informacin es tan completa como puede ser, es el momento de considerar igualar tcnicas de escalamiento a los componentes. Capacidad de administracin, la seguridad y la disponibilidad son factores crticos en todas las decisiones de diseo. No utilice tcnicas que proporcionan escalabilidad sino comprometer cualquiera de los factores antes mencionados crticos-. Elija una de las tcnicas de escalamiento siguientes: Utilizacin de un equipo ms rpido - Usando mltiples mquinas - Creacin de clusters - El uso de servidores de electrodomsticos - Segmentacin de la carga de trabajo - Uso de las solicitudes de lotes - La agregacin de datos de los usuarios - Gestin de conexiones - Uso de tcnicas de almacenamiento en cach - Uso de tcnicas inteligentes de virtualizacin de 5. Aplicar las tcnicas. Las pruebas son clave para la implementacin de la aplicacin exitosa. Es crucial que determinar no slo si las tcnicas de escalamiento son eficaces, pero que no afecten negativamente a otras reas. Tenga en cuenta que todos los componentes que conforman la infraestructura para su entorno de aplicacin debe ser equilibrado. Slo cuando se han logrado los resultados deseados si se trasladase a la produccin. 6. Vuelva a evaluar. Reconocer que cualquier sistema es dinmico. La infraestructura inicial en algn momento necesita ser revisado y ampliado, posiblemente. Los cambios en la naturaleza de la carga de trabajo puede crear la necesidad de volver a evaluar el entorno actual. Los grandes aumentos en el trfico requerir el examen de las configuraciones de la mquina. La escalabilidad no es una consideracin vez un diseo, es parte del crecimiento del medio ambiente-.

El artculo Diseo developerWorks para Escalabilidad Una actualizacin proporciona una discusin detallada sobre estos pasos. Se puede acceder a la siguiente pgina Web: http://www.ibm.com/developerworks/websphere/library/techarticles/hipods / scalability.html Estamos ampliando algunas de las tcnicas de escalamiento en el Captulo 7, "Rendimiento, escalabilidad, y alta disponibilidad "en la pgina 229.

4.2.2Caching
Cachinges una tcnica ampliamente utilizada para mejorar el rendimiento de los entornos de servidor de aplicaciones. Si la planificacin de un sitio web de alto volumen, almacenamiento en cach muy probable que sea necesario para lograr resultados satisfactorios de desempeo a un costo aceptable. WebSphere Application Server proporciona muchas caractersticas de almacenamiento en cach diferentes en diferentes lugares en la arquitectura. WebSphere Application Server Network Deployment proporciona funciones de almacenamiento en cach en cada nivel posible de la infraestructura: Infraestructura borde: Caching Proxy proporcionada por el Edge Components de WebSphereProxy Server capaservidor HTTP: Edge Side Include (ESI) cach fragmentada capacidades proporcionadas por el plug-in de WebSphere Caching capacidades del servidor HTTP en s (como el ayuno Cache Accelerator de respuesta (FRCA) segn lo dispuesto por la mayora de las implementaciones de IBM HTTP Server) Aplicacincapa del servidor: Servicio de almacenamiento en cach dinmico dentrodel servidor de aplicaciones JVM del servidorproxy WebSphere Adems de las caractersticas de almacenamiento en cach proporcionados por WebSphere Application Server Network Deployment, es posible considerar el uso de tercero cach dispositivos externos de almacenamiento en cach o infraestructuras proporcionadas por IBM y de terceros. Para utilizar los mecanismos de cach proporcionados por WebSphere Application Server y otros componentes de su entorno, la aplicacin debe estar diseado para almacenar en cach tambin. Por lo tanto, se sugiere el diseo de almacenamiento en cach en estrecha colaboracin con el arquitecto de aplicaciones. Despus de que haya terminado con el diseo de sus lugares de cach de completar el diseo de su aplicacin para incluir los componentes de almacenamiento en cach.

4.2.3 Alta disponibilidad

El diseo de una infraestructura de alta disponibilidad significa disear una infraestructura de manera que su entorno puede sobrevivir al fallo de los componentes de uno o mltiples. Alta disponibilidad implica redundancia evitando cualquier punto nico de fallo en cualquier capa (red, hardware, procesos, y as sucesivamente). El nmero de fallar los componentes de su entorno tiene que sobrevivir sin perder el servicio depende de los requisitos para el entorno especficoinfraestructura:. La siguiente lista ayuda a identificar las necesidades de alta disponibilidad de su Hablar con el patrocinador de su proyecto para identificar las necesidades de alta disponibilidad para cada uno de los servicios utilizados. Debido a la alta disponibilidad en la mayora de los casos significa la redundancia, esto tambin significa que la alta disponibilidad aumentar el costo de la implementacin.

No todos los servicios tiene los mismos requisitos de alta disponibilidad. Por tanto, sera una prdida de tiempo para planificar la plena disponibilidad alta para este tipo de servicios. Tenga cuidado al evaluar, como la alta disponibilidad de los sistemas enteros depende de la componente menos disponible. Con cuidado, se renen dnde y qu tipo de alta disponibilidad que realmente necesita para poder cumplir con el acuerdo de nivel de servicio (SLA) y los requisitos no funcionales. Cuando haya reunido los requisitos de alta disponibilidad, revise todos los componentes del diseo de la aplicacin que se desarroll en 4,1 , "Infraestructura de planificacin" en la pgina 94, y determinar la importancia de este componente es la disponibilidad del servicio, y cmo una falla podra afectar la disponibilidad de su serviciolista:. Evale cada componente que identific en el paso anterior en contra de la siguiente - Qu tan importante es el componente para el servicio de-. la criticidad del componente tendr un impacto en las inversiones que estn dispuestos a tomar para que este componente de alta disponibilidad Considere la posibilidad de un mantenimiento regularsituaciones. Adems de las fallas de los componentes, considerar el mantenimiento y colgar las . - Es el servicio bajo su controlcontrol?. veces eres acuerdo con los componentes de la arquitectura que estn fuera de su Por ejemplo, los servicios externos proporcionados por otra persona-.. Si el componente est fuera de su control, este documento como un riesgo adicional e informar al promotor del proyecto Qu hay que hacer para que el componente de alta disponibilidaduna? A veces hay ms de opcin de hacer un componente de alta disponibilidad. Tienes que hacer una seleccin, como a los que mejor se adapte a sus necesidades -.La aplicacin manejar las interrupciones de una manera definidacomponente?. Consulte a los desarrolladores de aplicaciones sobre cmo trata la aplicacin de un corte de un En funcin del componente y la situacin de error, la aplicacin puede necesitar un diseo especfico o la recuperacin de errores codificados antes de usar caractersticas de alta disponibilidad de la infraestructura -.D prioridad a sus inversiones de alta disponibilidadarchivo. Decidir la aplicacin de alta disponibilidad basada en la criticidad del componente y el corte de tasa esperada. Documentar cualquier desviacin de la recogida de requisitos -.Tamao de cada componente en una forma que pueda proporcionar capacidad suficiente, incluso en caso de fallo de un componente redundantealta. Despus de que haya terminado con su diseo de alta disponibilidad, actualizar el diseo de su aplicacin para incluir el caractersticas de disponibilidad.

4.2.4 Balanceo de carga y conmutacin por

error-Comoresultado de las consideraciones de diseo para la alta disponibilidad es muy probable que identificar una serie de componentes que necesitan redundancia. Contar con sistemas redundantes en una arquitectura requiere que usted piense acerca de cmo implementar esta redundancia para asegurar obtener el mayor beneficio de los sistemas durante las operaciones normales, y cmo va a gestionar una perfecta conmutacin por error en caso de fallo de un componente. Esto introduce las siguientes tcnicas para el diseo: Equilibrio de carga Equilibrio de carga es la tcnica de repartir la carga a travs de mltiples copias de un componente para un uso ptimo de los recursos disponiblesautomticamente. Fail-over Fail-over es la capacidad de detectar la falla de un componente de solicitudes y la ruta de todo el componente que ha fallado. Cuando el recurso no est disponible, ser determinado automticamente por el sistema y vuelve a unir de manera transparente el procesamiento de carga de trabajo.

Para el diseo de balanceo de carga y conmutacin por error, lo que necesita saber cada componente de equilibrio de carga y conmutacin por error de capacidades y cmo pueden ser utilizado. Dependiendo de las caractersticas que se utiliza y cmo lograr estas capacidades, se requieren hardware y software adicionales para obtener una alta disponibilidad. En un entorno de servidor WebSphere Application tpico, hay una gran variedad de componentes que necesitan ser considerados en la aplicacin de equilibrio de carga y habilidades fail-over: almacenamiento en cach de servidores proxy HTTP servidores de contenedores (como la Web, SIP, y los contenedores de portlets) Enterprise JavaBeans (EJB) contenedores Motores de mensajera Back-end sirve (bases de datos, sistemas de informacin empresariales, etc) Registros de usuario mientras que la carga capacidades de equilibrio y no sobre-para algunos de estos componentes se incorpora en WebSphere Application Server, otros requieren hardware adicional y software. Por ejemplo, para lograr una alta disponibilidad para los servidores HTTP o servidores proxy inversos, es necesario pulverizadores de propiedad intelectual frente a la servidores HTTP o servidores proxy inversa. Por el contrario, habilidades fail-over para la mensajera por omisin de WebSphere es proporcionada por el administrador de aplicaciones WebSphere disponibilidad de servidores de alta densidad (HAManager) cuando utilice clsteres de WebSphere. Tenga en cuenta que el HAManager requiere almacenamiento compartido entre todos los miembros del clster para poder conmutacin por error del servicio de mensajera. Despus de que haya terminado su balanceo de carga y conmutacin por error discusin, actualizar el diseo de su aplicacin para incluir estas caractersticas tambin.

4.2.5 La recuperacin de desastres

recuperacin de desastres es un requisito diferente de alta disponibilidad. En 4.2.3, "Alta disponibilidad" en la pgina 99, discutimos algunas consideraciones acerca de lo que hay que hacer para asegurarse de que nuestros servicios son de alta disponibilidad. Por ejemplo, un corte de luz de un solo componente no traer nuestro servicio hacia abajo. Alta disponibilidad general se puede lograr evitando cualquier punto nico de fallo en la arquitectura y la provisin de recursos suficientes. Recuperacin de desastres se centra en las acciones, procesos y preparaciones para recuperarse de un desastre que ha golpeado a su infraestructura. Puntos importantes para la planificacin de recuperacin de desastres son los siguientes: Objetivo de Tiempo de Recuperacin (RTO) Cuntotiempo puede pasar antes de que el componente no debe estar en funcionamientoaccesible? Objetivo de Punto de Recuperacin Cunta (RPO)prdida de datos es El RPO establece el intervalo para el que no se puede copia de seguridad de los datos proporcionados. Si no hay ninguna prdida de datos puede ser otorgada, la RPO sera cero. Planificacin para la recuperacin de desastres es una tarea compleja, y requiere de una planificacin de extremo a extremo para todos los componentes del centro de datos. Para obtener informacin sobre WebSphere Application Server y la recuperacin de desastres, consulte el artculo de developerWorks Todo lo que usted siempre quiso saber acerca de WebSphere Application Server, pero se atrevi a preguntar, Parte 5 disponible en la siguiente pgina Web: http://www.ibm.com/ developerworks/websphere/techjournal/0707_col_alcott / 0707_col_alcott.html

4.2.6 Seguridad de
WebSphere Application Server V7.0 es un potente basado en Java, servidor de aplicaciones middleware listo para ejecutar sus aplicaciones de misin crtica y las transacciones comerciales.

Por esta razn tenemos que disear la seguridad adecuada en nuestra infraestructura de WebSphere Application Server desde el inicio de la fase de diseo. WebSphere Application Server proporciona una infraestructura de seguridad en continua expansin y flexible que puede utilizar para hacer que el acceso a sus aplicaciones y datos ms seguros. El modelo de seguridad de WebSphere Application Server se ha mejorado en la versin 7.0 mediante la adicin de las siguientes caractersticas (para ms informacin vea 12.1, "Qu hay de nuevo en V7.0" en la pgina 380): Soporte para mltiples dominios de seguridad seguridadde auditora Mejoras depara la gestin de certificados SPNEGO Kerberos y soporte para Java EE 5 Soporte de seguridadAnotaciones
un

Kerberosapoyo no es parte de los productos bsicos, pero est previsto que est disponible en un paquete de arreglos futuro

es responsable de la infraestructura de WebSphere Application Server para proporcionar todos los servicios requeridos por las aplicaciones se ejecuten en un entorno seguro. Es imprescindible entonces, tener en cuenta la seguridad en la planificacin de una infraestructura de WebSphere Application Server. En muchos casos se encuentran los componentes reutilizables de una infraestructura de seguridad ya existentesinfraestructura:.. en cuenta cmo afectar a la seguridad de su Entender la poltica de seguridad y los requisitos para su futuro entorno de trabajo con un experto en materia de seguridad para desarrollar una infraestructura de seguridad que se adhiere a los requisitos y se integra en la infraestructura existente. Asegrese de que la seguridad fsica suficiente en su lugar. Asegrese de que los desarrolladores de aplicaciones de comprender los requisitos de seguridad y cdigo de la aplicacin correspondiente. Considere el registro de usuario (o registros) que va a utilizar. WebSphere Application Server V7.0 soporta mltiples registros de usuarios y mltiples dominios de seguridad. Asegrese de que los registros de usuarios no estn violando los requisitos de alta disponibilidad. Aunque los registros de usuarios que est utilizando son de alcance del proyecto de WebSphere Application Server, las consideraciones para la alta disponibilidad es necesario tomar y solicitado. Por ejemplo, asegrese de que los registros de usuarios de LDAP se realizan con alta disponibilidad y no son un punto nico de fallo. Definir el dominio fiduciario para su entorno. Todos los equipos en el mismo dominio de seguridad de WebSphere confiar en los dems. Este dominio fiduciario puede ser ampliada, y al utilizar SPNEGO / Kerberos, aunque fuera en el escritorio de Windows de los usuarios de la empresa. Evaluar el diseo de su aplicacin actual y garantizar que todo acceso posible a los sistemas est asegurada. Considere el nivel de auditora requerido y la forma de ponerla en prctica. Considere cmo proteger los datos almacenados. Piense en la seguridad del sistema operativo y el cifrado de los datos almacenados. Definir una poltica de contraseas, incluyendo consideraciones para el manejo de caducidad de contraseas para los usuarios individuales. Considere los requisitos de cifrado para el trfico de red. Cifrado introduce costos de los recursos generales y el aumento, por lo que utilizar el cifrado slo en su casovencimiento:.. definir el cifrado (SSL) puntos finales en sus comunicaciones Plan de certificados y su Decida qu trfico requiere certificados de una autoridad de certificacin de confianza y para que el trfico de un auto certificado firmado es suficiente. Las conexiones de seguridad con el mundo exterior suelen utilizar un certificado de

confianza, pero para las conexiones dentro de la empresa, los certificados autofirmados suelen ser suficientes. Desarrollar una estrategia de gestin de los certificados. Muchas autoridades de certificacin de confianza proporcionan las herramientas en lnea que apoyan la gestin de certificados. Pero qu pasa con los certificados autofirmados Cmovas a copia de seguridad de los certificados? Siempre tenga en cuenta que los certificados son la clave de sus datos. Los datos cifrados no sirve para nada si pierde sus certificados. Planee cmo va a obtener sus certificados. Los certificados son la clave de sus datos, por lo tanto, asegrese de que estn garantizados y respaldados apropiadamente-. Nota: Otras sugerencias y consejos para WebSphere Application Server consideraciones de seguridad relacionadas se describen en IBM WebSphere Developer Technical Journal artculo WebSphere Application Server V6 avanzado endurecimiento de la seguridad Parte1, disponible en la pgina Web siguiente: http://www.ibm.eom/developerworks/websphere/techjournal//0512_botzum / 0512_botzuml.html Despus de haber terminado sus consideraciones de seguridad, actualizar el diseo de su aplicacin para incluir todos los componentes relacionados con la seguridad .

4.2.7 Implementacin de la aplicacin

Cuando la planificacin de la infraestructura de WebSphere Application Server, no se demore pensamientos de implementacin de aplicaciones hasta que la aplicacin est lista para desplegarse. Iniciar esta tarea de planificacin cuando se inicia el diseo de su infraestructura. La forma de implementar la aplicacin afecta el diseo de la infraestructura de varias maneras:.Rendimiento La forma de implementar la aplicacin puede afectar al rendimiento de forma significativa. Las pruebas mostraron diferencias significativas en el rendimiento al implementar Enterprise Java Bean (EJB) mdulos para el mismo servidor de aplicaciones como los componentes de cliente EJB, en comparacin con el despliegue de mdulos EJB en un servidor de aplicacin por separado de los componentes de cliente EJB. Implementacin de mdulos EJB a los servidores de aplicaciones independientes, sin embargo , da mucha ms flexibilidad y evita la duplicacin de cdigo. Nmero de servidores de aplicaciones Al planear la implementacin de mltiples aplicaciones en su entorno usted puede desplegar mltiples aplicaciones para el mismo servidor de aplicaciones o crear un servidor para cada aplicacin. En funcin de la decisin que podra terminar con un mayor nmero de servidores de aplicaciones en tu celular. Esto significa que usted tendr una celda ms grande, lo que implica un mayor tiempo de inicio del servidor y la complejidad de su entorno debido a las grandes vistas de alta disponibilidad. Cluster comunicacin Cuanto mayor sea el nmero de servidores de aplicaciones, mayor es la sobrecarga de comunicaciones y sistemas de gestin en su medio ambiente. plataformas WebSphere Application Server admite la creacin de plataformas clulas. Esto significa que puede crear una celda que contiene servidores en mltiples plataformas. Si bien esta opcin aumenta la complejidad del entorno y hace que la administracin sea ms complicado, le da una gran flexibilidad a la hora de la integracin de componentes de software existentes. Despus de saber cmo las aplicaciones se pueden implementar, actualizar el diseo de su aplicacin.

4.2.8 Servicability

Plan para las tareas de determinacin y servicability problema para su entorno. La planificacin de servicability incluye la planificacin de las herramientas, la educacin, los requisitos de disco para depuracin de datos, requerimientos de comunicaciones, agentes necesarios para sus herramientas, etc Nota:. WebSphere Application Server V7.0 viene con IBM Support Assistant V4.0 que ofrece muchas herramientas para Anlisis de problemas y toma de datos. Consulte las siguientes pginas Web para ms informacin: http://www-01.ibm.com/software/support/i

Dimensionamiento de la infraestructura
Despus de determinar la demanda inicial y diseo de infraestructuras y tcnicas de escalabilidad, es necesario determinar los recursos del sistema necesarios para el proyecto de mantener los acuerdos de nivel de servicio (SLA). Siempre que la toma de decisiones dimensionamiento asegurar que todas las decisiones de diseo son todava honrado. Diseo de aplicaciones evolucionar con el tiempo, y el tamao se suele hacer en las primeras etapas de diseo. Sin embargo, al determinar el tamao, es importante que usted tiene una versin esttica del diseo de la aplicacin con la que trabajar. La mejor visin que usted tiene de diseo de la aplicacin, la mejor estimacin de su tamao ser. Usted tiene que considerar que las plataformas de hardware que desea utilizar. Esta decisin depende de los siguientes Escala de capacidades de lasde la plataforma plataformasWebSphere Application Server soporta el factores:.desempeo, la seguridad y los requisitos de alta disponibilidad de su entorno continuacin, determine el enfoque de escala: Escalaarriba-verticalampliacin Escala se lleva a cabo dentro de un solo sistema, por lo general en una mquina multiprocesador. Aunque este enfoque puede ser suficiente desde la perspectiva del rendimiento, el hardware subyacente son los puntos nicos de falla. Escalafuerahorizontal horizontal de escalaescaladosignifica aumentar el nmero de mquinas. El escalado se hace generalmente para mejorar la alta disponibilidad mediante la limitacin de los puntos nicos de fallo, as como por motivos de escalabilidad cuando los recursos de hardware son el factor limitante. Hay que apoyar y mantener varias mquinas. Si decide utilizar la escala el planteamiento tenga en cuenta que su diseo debe ser capaz de procesar la carga de trabajo, incluso si un sistema falla. Estimaciones de tallas se basan nicamente en su entrada, lo que significa que cuanto ms precisa es la de entrada, mejores sern los resultados. Acerca de tallas trabajo asume un nivel medio de rendimiento de las aplicaciones y el comportamiento de un tiempo medio de respuesta se asume para cada transaccin. Los clculos basados en este se realizan para determinar el nmero estimado de mquinas y transformadores de su aplicacin se requieren. Si su empresa cuenta con un equipo de experiencia del usuario, que podran haber documentado los estndares para un tiempo de respuesta tpico de que su nuevo proyecto tiene la obligacin de cumplir. Si necesita una estimacin ms precisa de los requisitos de hardware y ya tiene su aplicacin, considere el uso de un los servicios de referencia se tratan en 4.4, "Benchmarking" en la pgina 107. Sobre la base de su estimacin, es posible que tenga que actualizar el diseo de la implementacin para todos sus ambientes planeados. Los cambios en el entorno de produccin deben ser incorporados en los entornos de desarrollo y prueba si es posible. Si esto no es posible por motivos presupuestarios, asegurarse de que la integracin y el entorno de desarrollo son funcionalmente equivalentes. Asegrese para validar el apresto con una prueba de carga antes de iniciar la produccin.

4,4Benchmarking
Benchmarkinges el proceso utilizado para determinar la capacidad de un entorno de aplicacin a travs de pruebas de carga. Esta determinacin le permite hacer juicios razonables como su entorno comienza a cambiar. Utilizando los puntos de referencia, se puede determinar la capacidad de trabajo entorno actual y establecer las expectativas como las nuevas aplicaciones y componentes son introducidos. Muchas empresas mantienen un punto de referencia de la pila de aplicaciones y cambiarlo despus de cada lanzamiento o actualizacin de un componente. Estos clientes suelen tener bien desarrolladas entornos de prueba de aplicaciones y equipos dedicados a la evaluacin comparativa. Para aquellos que no lo hacen, otras alternativas como el centro de pruebas de IBM estn disponibles. Tambin hay otras compaas de referencia que proporcionan este servicio Nota:. Se recomienda incluir una referencia o prueba de carga como parte del proceso de desarrollo. Esto evitar un montn de problemas de rendimiento y ayudar a mejorar la calidad del cdigo de la aplicacin, as como la solidez del medio ambiente en general.

Test Center de IBM

IBM Global Services ofrece la gestin del rendimiento, pruebas y servicios de escalabilidad. Este equipo va a venir en el sitio y evaluar el desempeo general del sitio. Esta investigacin es una plataforma neutral. Las ofertas incluyen, pero no estn limitados a los siguientes servicios: Servicios de ensayo y escalabilidad para redes TCP / IP de prueba y servicios de escalabilidad para el sitio Webestrsanlisis Performance Engineeringyde procesos de pruebaConsulting Pruebas de Rendimiento yValidacin Afinacinde rendimiento y optimizacin de la capacidad Cuando se utiliza un servicio como como los proporcionados por el Centro de Pruebas de IBM, se le presentar con una gran cantidad de documentacin y pruebas que respalden los resultados de las pruebas. Yo u puede utilizar estos datos para ajustar su entorno actual.

4.5rendimientoEl rendimiento
Ajuste del es uno de los ms importantes requisitos no funcionales para cualquier entorno de WebSphere. Rendimiento de las aplicaciones debe ser seguido continuamente durante el proyecto. Cuando el proyecto est terminado y se cambia el medio ambiente en la produccin, es necesario estar seguro de que el medio ambiente puede manejar la carga de usuarios. Los problemas de rendimiento son, con mucho, la ms visible para el usuario problema que usted pueda tener. La mayora de los usuarios estn dispuestos a aceptar pequeos problemas de funcionamiento cuando un sistema es lanzada al mercado, pero los problemas de rendimiento son inaceptables para la mayora de usuarios y afectan a todos los que trabajan en el sistema. Asegrese de realizar las pruebas de carga que representan una carga de usuarios realista contra el sistema.

4.5.1 cuestiones de diseo de aplicaciones

Muchos de los problemas de funcionamiento que no puede solucionar mediante el uso de ms hardware o cambiar los parmetros de WebSphere. Como tal, usted realmente tiene que hacer pruebas de funcionamiento y puesta a punto parte de su proceso de desarrollo y ciclos de lanzamiento para evitar problemas en el futuro. Las pruebas de rendimiento y puesta a punto debe tenerse en cuenta en la programacin del proyecto Nota:. Se sugiere el desarrollo de aplicaciones para utilizar las tcnicas de aplicacin de perfiles. Esto permite que el equipo de desarrollo para identificar los cuellos de botella en las aplicaciones y los puntos calientes donde se consume una gran cantidad de recursos de CPU. Por lo general, muchos de los puntos calientes se pueden quitar con poco esfuerzo. Hace falta mucho ms esfuerzo y dinero para corregir los problemas despus de que se produjo en la produccin de fijarlos en la delantera. Si las pruebas de rendimiento es parte de su ciclo de desarrollo, que son capaces de corregir problemas con el diseo de su aplicacin mucho ms temprano, lo que resulta en un menor nmero de problemas al utilizar la aplicacin en el entorno de produccin.

4.5.2 Entender sus necesidades,

sin una clara comprensin de sus necesidades, usted no tiene ninguna meta para sintonizar en contra. Es importante cuando se hace el ajuste de rendimiento contar con objetivos especficos los siguientes: Transacciones por segundo Rendimiento Un marco de tiempo mximo, para aplicaciones de estilo de lote mximo los recursos utilizados no pierdas tiempo afinando el rendimiento de un sistema que era de tamao inadecuado y no pueden soportar la carga. . Para identificar un objetivo bien hay que entender los requerimientos no funcionales, as como el dimensionamiento de su entorno de

configuracin del entorno de prueba 4.5.3

Al ejecutar pruebas de rendimiento, siga estos consejos generales: Ejecutar las pruebas en un entorno de produccin-como. El uso de un medio ambiente que es lo ms cercano posible al entorno de produccin le permite extrapolar los resultados de las pruebas para el entorno de produccin. Si usted est comenzando con un nuevo entorno utilizar el entorno de la futura produccin para las necesidades de su prueba antes de publicarla. Acceso exclusivo para el medio ambiente para la prueba. Asegrese de que nadie est utilizando los sistemas de prueba y que no se estn ejecutando procesos en segundo plano que consumen ms recursos que lo que se encuentra en produccin. Por ejemplo, si la intencin es poner a prueba el rendimiento durante la copia de seguridad de base de datos, asegrese de que la copia de seguridad est en marcha. Uso de opciones de monitorizacin. Cuando se implementa un entorno WebSphere Application Server, se aconseja el uso de herramientas de monitoreo para controlar la salud del medio ambiente. Durante las pruebas de rendimiento, hay dos niveles de control a realizar: - Seguimiento de depuracin El objetivo es identificar posibles cuellos de botella o las razones de los problemas. El nivel de depuracin se detalla y utilizar recursos adicionales, por lo general afectan a los resultados de las pruebas-. de control de produccin Despus de identificar y resolver problemas de rendimiento con el seguimiento de depuracin, realice una prueba con el mismo conjunto de opciones de control que se utilizarn posteriormente en el entorno productivo. Con esta opcin, usted debe ser capaz de satisfacer los acuerdos de nivel de servicio. el uso de recursos Monitor. Compruebe el uso de procesador, memoria y disco antes, durante y despus de cada prueba para ver si hay algn patrn inusual. Si el entorno de destino est utilizando una infraestructura compartida, asegrese de que el componente compartido est llevando a cabo bajo la carga proyectada compartido. aislar el trfico de red tanto como sea posible. Uso de interruptores, rara vez hay una circunstancia en la que el trfico procedente de un servidor excesos de un puerto de otra. Es posible, sin embargo, a los puertos de inundacin utilizado para el encaminamiento de la red a otras redes o incluso el esqueleto de interruptor para el trfico pesado. Asegrese de que la red asla el entorno de prueba tanto como sea posible antes de la partida, ya que la degradacin del rendimiento de la red puede generar resultados inesperados. Realizar pruebas repetitivas. Reinicie el sistema a un estado inicial definido. Esto incluye la base de datos, las memorias cach, y as sucesivamente. Las bases de datos que utilizan conjuntos de datos hasta que se restablezca en particular. Asegrese de que tiene suficiente informacin sobre pruebas disponiblessiguientes:.

4.5.4 Factores de carga

Los factores ms importantes que determinan cmo llevar a cabo las pruebas de carga son los Solicitar tasa concurrentesde los usuarios patrones de uso Esta no es una lista completa y otros factores pueden ser ms importantes en funcin en el tipo de sitio que se est desarrollando.

tasa de Solicitud
La tasa de solicitud representa el nmero de solicitudes por unidad de tiempo. En entornos basados en Web esto es principalmente expresada en nmero de peticiones HTTP por segundo. Es muy importante que la tasa de solicitud se encuentra cerca de las expectativas reales de carga de palabras.

Usuarios
simultneos,el de usuarios concurrentes nmeroexpresa el nmero de usuarios al mismo tiempo que solicitan servicio de su entorno en un punto en el tiempo. Este nmero de usuarios que realmente est disparando peticiones al sistema en un punto dado de tiempoexisten:. en contraste a los usuarios simultneos que usuarios usuariosActive expresa todos los usuarios actualmente utilizando los recursos (por ejemplo, en forma de datos de la sesin) en su entorno. Tambin incluye a los usuarios que estn leyendo la respuesta, la introduccin de datos, etc. Usuarios Nombrados los usuarios con nombre usuariossonque se definen en el medio ambiente en general. Esto suele ser un nmero grande en comparacin con el nmero de usuarios concurrentes.

Los patrones de uso

en este punto en el proyecto, es importante que tengas en cuenta cmo los usuarios van a utilizar el sitio. Es posible que desee utilizar los casos de uso que los desarrolladores se definen por su diseo de la aplicacin como un insumo para construir sus patrones de uso. Esto hace que sea ms fcil de construir los escenarios despus de que la prueba de carga se utilizanfactores:. patrones de uso integrado por los siguientes Los casos de uso modelan como hacer clic a travs de los flujos de pginas pesos aplicados a sus casos de uso de pesos de combinacin con las corrientes clic es importante porque muestra nmero de usuarios que se espera en la que los componentes de la aplicacin, y donde se generan carga. Despus de todo, es un tipo diferente de carga si se espera un 70% de sus usuarios a buscar su sitio en lugar de navegar a travs del catlogo que viceversa. Estos supuestos tambin tienen un impacto en su estrategia de almacenamiento en cach. Notifique a sus desarrolladores de sus resultados para que puedan aplicarlas a su esfuerzo de desarrollo. Asegrese de que los casos de uso ms comunes son aquellos en los que la mayor parte del trabajo se lleva a cabo la optimizacin del rendimiento. Para utilizar esta informacin ms adelante cuando se graban los escenarios de prueba de carga, se sugiere que se escribe un informe con capturas de pantalla o direcciones URL para los flujos de clic (comportamiento de usuario). Incluya las ponderaciones de los casos de uso para mostrar la forma en que la carga de los encuestados se distribuy.

4.5.5 Sistema de produccin tuning

Aqu es donde se aplica todo el rendimiento, escalabilidad y alta disponibilidad en la produccin. Ajuste del sistema es un proceso iterativo que implica la optimizacin de los parmetros de WebSphere para adaptarse a su entorno de ejecucin Importante:. Para utilizar la sintonizacin en el entorno de produccin, tener la versin final del cdigo que se ejecuta. Esta versin debera haber pasado las pruebas de rendimiento en el

entorno de integracin antes de cambiar ningn parmetro de WebSphere en el sistema de produccinestndar:... Cuando se cambia un entorno de produccin, utilice algunas de las prcticas Cambie slo un parmetro a la vez Documentar todos los cambios de comparacin prueba corre a varios la lnea de base. Cambios entre las ejecuciones de prueba no debern diferir en ms de un pequeo porcentaje de impedir la introduccin de los nuevos problemas que usted pueda necesitar para resolver antes de continuar afinacin. Tan pronto como termine afinar sus sistemas de produccin, aplicar la configuracin a sus entornos de prueba para asegurarse de que son similares a la produccin. Planee volver a ejecutar las pruebas all para establecer nuevas bases de referencia sobre estos sistemas y ver cmo estos cambios afectan al rendimiento. Tenga en cuenta que a menudo slo tienen una oportunidad para hacerlo bien. Por lo general, tan pronto como usted est en produccin con el sistema, no se puede ejecutar pruebas de rendimiento en este entorno ms, simplemente porque usted no puede tomar el sistema de produccin en lnea para realizar ms pruebas de rendimiento. Si un sistema de produccin est siendo probado, es probable que el sistema est funcionando en una posicin muy degradado, y que ya han perdido la mitad de la batalla Nota:. Debido a que es raro utilizar un sistema de produccin para las pruebas de carga, es generalmente un mala idea para migrar estos entornos a las nuevas versiones de WebSphere sin hacer una prueba adecuada en un sistema de prueba equivalente o hardware nuevo. Despus de completar sus pruebas de rendimiento primero y ajuste de los parmetros WebSphere, evaluar sus resultados y compararlos con los objetivos para ver cmo todos esto funcion para ticonsecuencia:.

4.5.6 Conclusiones
Existen varios posibles resultados de sus pruebas de rendimiento que usted debe entender claramente y actuar en Rendimiento cumpla con sus objetivosfuturo. Si el rendimiento se ajuste a sus objetivos, asegrese de que usted ha planeado para el crecimiento y de que estn cumpliendo todos los objetivos de rendimiento. Despus de eso, se sugiere documentar sus hallazgos en un informe de la optimizacin del rendimiento y el archivo de la misma. Incluye todos los ajustes que haya modificado para alcanzar sus objetivos. Este informe es til al configurar un nuevo entorno o cuando se tiene que duplicar sus resultados en otro lugar en un entorno similar con la misma aplicacin. Estos datos son esenciales al agregar rplicas adicionales de algunos componentes en el sistema, ya que necesitan estar configurados con la misma configuracin que utilizan los recursos actuales. Rendimiento es ms lento de lo necesario. Si el rendimiento de las aplicaciones es algo ms lento de lo esperado, y ya han hecho todo lo posible aplicacin y puesta a punto de WebSphere parmetro, es posible que tenga que agregar ms hardware (por ejemplo, aumentar la memoria, los procesadores de actualizacin, etc) a los componentes de cuello de botella en su entorno. A continuacin, ejecute de nuevo las pruebas. Verifique con los equipos adecuados que no haba perdido los cuellos de botella en el flujo general del sistemasiguientes:.. Rendimiento es significativamente ms lento que requiere en este caso, se debe empezar de nuevo con su tamao y haga las preguntas Saba usted que subestimar ninguna de las caractersticas de la aplicacin durante su tamao inicial? Si es as, por qu? Se subestiman el trfico y nmero de usuarios / visitas en el sitio? Sigue siendo posible cambiar partes de la aplicacin para mejorar el rendimiento? Es posible obtener recursos adicionales?

Despus de responder a estas preguntas, usted debe tener una mejor comprensin sobre el problema que usted enfrenta. Su mejor apuesta es analizar la aplicacin y tratar de encontrar los cuellos de botella que causan sus problemas de rendimiento. Las herramientas como el Analizador de que forma parte de la Asamblea Rational Application Developer y desplegar V7.5 y Rational Application Developer para WebSphere Software V7.5 puede ayudar.

4.6 Planificacin la vigilancia a

dela mayora de aplicaciones basado en WebSphere son aplicaciones basadas en Internet, una disponibilidad 24x7 es una necesidad. La tolerancia de los usuarios de Internet para los sitios no disponibles es baja y los usuarios suelen desplazarse a la siguiente pgina si su sitio no es operable. Esto significa que usted acaba de perder a un cliente potencial. Es necesario entonces, hacer un seguimiento y monitorear la disponibilidad de su sitio para que usted reconozca cuando las cosas van mal y pueden reaccionar de manera oportuna. Un control eficiente, combinado con un sofisticado alerta y procedimiento de tramitacin de problema, puede aumentar la disponibilidad de su servicio de manera significativa. Es por eso que usted debe planear para el monitoreo y manejo de problemas. No espere hasta que su entorno se convierte en improductivo.

4.6.1 Anlisis Ambiental para el seguimiento de

la planificacin cuidadosa para el seguimiento es esencial y debe comenzar con un anlisis detallado del medio ambiente a monitorear. Es importante asegurarse de que el entorno completo se controla y no solo componente supervisado hacer:. esanalizar los requisitos de control para el entorno de considerar los siguientes factores para dar una visin general de lo que hay que

Componentes a ser
monitoreados,es esencial que cada componente necesario para ejecutar el servicio se controla. Para cada componente se identifica, conteste las siguientes Cules preguntas:son los posibles estados de los componentes y cmo puedes recuperar Cul es el impacto de cada uno de los estados posibles del componente puede tener locontrolar? que los atributos especficos del componente se puede Paracada atributo se puede controlar, definir los siguientes valores: Quvalores de atributo (o rango de valores de atributos) muestran un estado normal del componente Cules son los valores de atributo (o rango de valores de atributos) muestran una situacin que requiere la atencin del administrador (nivel de advertencia)? Qu valores de atributo (o rango de valores de atributos) muestran una condicin crtica para el componente y requieren una accin inmediata administrador (alerta)? prioridad a cada uno de los componentes de los resultados del monitoreo y definir las acciones a tomar.

software de monitoreo
para proporcionar eficiente 24 7 supervisin, es necesario utilizar algn tipo de software de monitoreo. Muchas organizaciones cuentan con alguna infraestructura de vigilancia en el lugar. Determine si usted puede volver a utilizar esto para la infraestructura de WebSphere Application Server tambin.

Agentes de
controlen funcin del software de monitoreo en uso, agentes de supervisin para ciertos componentes estn disponibles. De lo contrario, la mayora del software de seguimiento proporciona algunas interfaces de secuencias de comandos que le permiten escribir sus propios guiones. Las secuencias de comandos comprobar y generar los resultados que el software de monitoreo puede analizar.

Las necesidades de infraestructura

de monitoreo Cuando se ejecuta en el entorno que necesita para planificar recursos adicionales. Monitoreo afecta a su entorno en casi todos los aspectos. La vigilancia requiere de memoria, ciclos de CPU, red de comunicaciones, e incluso puede requerir diferentes sistemas adicionales para puertas de enlace (o como sistemas de servidor) para la solucin de monitorizacin. Asegrese de que todos los requisitos no funcionales para su infraestructura se aplican a estos sistemas tambin.

El monitoreo los niveles

Monitoreodeben estar en su lugar en todas las capas de la infraestructura. Yo u debe asegurar un seguimiento exhaustivo del medio ambiente. Yo u probablemente va a terminar con las tareas de supervisin y mltiples soluciones para diferentes propsitos. Supervisin de la red de monitoreo de red cubre toda la infraestructura de red como switches, firewalls, routers, etc. Tambin debe supervisar la disponibilidad de todas las vas de comunicacin, incluidas las vas de comunicacin redundantes. Monitoreo del sistema operativo ms soluciones de monitoreo proporcionan capacidades de vigilancia para los sistemas operativos compatibles. Con estas funciones le permite realizar un seguimiento de la salud de su entorno desde la perspectiva del sistema operativo y le permite controlar los componentes, como el uso de CPU, uso de memoria, sistemas de archivos, procesos, etc. Componentes Middleware monitoreo Al utilizar componentes de middleware, como la aplicacin servidores y bases de datos, el seguimiento en el nivel de sistema operativo no es suficiente, porque el sistema operativo no tiene conocimiento del estado de middleware. Es necesario un seguimiento especfico para el middleware que proporciona el entorno de ejecucin de la aplicacin. WebSphere Application Server ofrece varias interfaces que permiten el control de su infraestructura de servidor de aplicaciones. Muchos productos de monitorizacin populares, como la suite IBM Tivoli Composite Application Monitoring, el apoyo a estas interfaces y proporcionan listos para usar agentes para controlar su entorno de WebSphere Application Server. Monitoreo de Transacciones El Propsito del monitoreo transaccion es Controlar el Medio Ambiente desde la Perspectiva del usuario. Monitoreo de transacciones utiliza pregrabados transacciones o secuencias de clic y reproducirlas mediante el cual la respuesta de cada interaccin con el usuario repite se verifica con los resultados esperados.

4.6.2 rendimiento y tolerancia a fallos

que tener en cuenta que el control de su entorno (no importa en qu nivel) consume ms recursos. Asegrese de que la configuracin de monitorizacin no causa efectos inaceptables para el medio ambiente. Cuanto ms monitorear, y cuanto menor sea el intervalo entre los ciclos de monitorizacin, ms rpido se puede determinar algo fuera de lo comn. Pero cuanto ms monitorear, y cuanto menor sea el intervalo entre los ciclos de monitorizacin, cuanto mayor sea la sobrecarga que generan. La clave del xito es encontrar un buen equilibrio entre el seguimiento en intervalos cortos suficientes para determinar fallas sin consumir una cantidad inaceptable de recursos. Adems del impacto en el rendimiento, es necesario asegurarse de que cualquier problema en su infraestructura de monitorizacin no afectan su ambiente. Monitoreo, incluso si hay algo mal en la infraestructura de supervisin, no debe ser la causa de cualquier interrupcin del servicio.

4.6.3 Alerta yde resolucin de problemas

Seguimientopor s sola no es suficiente para realizar un seguimiento de la salud de su entorno, como la vigilancia no resuelve cuestiones. Se mejorar la disponibilidad si combinas con una adecuada vigilancia alertando a los solucionadores de problemas responsables. Cul es el uso

del monitoreo si nadie sabe que existe un problema? Algunos pensamientos que usted necesita considerar cuando se planifica para alertar

Quin es alertado por qu evento a:???Cules son los tiempos de respuesta requeridos Cmo sern los responsables sean alertados Cmo va a evitar alertas repetidas por los mismos hechos Cmo alertas y la resolucin de la de las alertas se documentar Quinhar un seguimiento de las alertas y resolucin de problemas? Quin est a cargo de la alerta hasta que se resuelva definitivamente, quin llevar a cabo el anlisis de causa raz para evitar la recurrencia de la alerta?

alerta es slo una primera parte de su gestin de incidentes y problemas. Para ms informacin y ms detalles sobre el incidente y la administracin de problemas se refieren a las pginas de ITIL en la pgina Web siguiente:
http://www.itlibrary.org/index.php?page=ITIL

4.6.4 Pruebas
Al igual que con todos los componentes del medio ambiente, no se olvide de probar su infraestructura de monitoreo con regularidad. Sobre todo si la aplicacin es nueva, probar todas las alertas nico de vigilancia y asegrese de que el monitoreo detecta cada condicin de su sistema correctamente. No suspenda la prueba cuando se ve una situacin de vigilancia levantada. Pon a prueba todo el proceso, incluida la alerta y gestin de incidentes y garantizar que las condiciones se restablecen automticamente tan pronto como la situacin ha vuelto a la normalidad.

4.7 Planificacin de copia de seguridad y recuperacin

En general, el hardware y el software es confiable, pero a veces pueden ocurrir errores y daos una mquina, dispositivo de red, software, configuracin, o ms importante, los datos empresariales. No hay que subestimar el riesgo de un error humano que pudiera conducir a daos. Es importante planear para tales casos. Hay una serie de etapas para crear un plan de copia de seguridad y recuperacin, lo que se discute en las siguientes secciones.

4.7.1 Anlisis de riesgos

El primer paso para crear una copia de seguridad y plan de recuperacin consiste en realizar un anlisis integral de riesgos. El objetivo es descubrir qu reas son las ms crticas y que tienen el mayor riesgo. Es importante identificar qu procesos de negocio son los ms importantes y se priorizan en consecuencia.

4.7.2 estrategia de recuperacin

Cuando las reas crticas han sido identificados, desarrollar una estrategia para la recuperacin de esas reas. Hay numerosos copia de seguridad y estrategias de recuperacin disponibles que varan en el tiempo de recuperacin y el costo. En la mayora de los casos, el coste aumenta a medida que disminuye el tiempo de recuperacin. La clave para la estrategia apropiada es encontrar el equilibrio adecuado entre el tiempo de recuperacin y el costo. El impacto en el negocio es el factor determinante en la bsqueda del equilibrio adecuado. Crticas para el

negocio procesos necesitan tiempo de recuperacin rpida para minimizar las prdidas de negocios. Por lo tanto, los costos de recuperacin son mayores.

4.7.3 plan de copia

de seguridad con la estrategia de recuperacin, un plan de copia de seguridad tiene que ser creado para manejar las operaciones de copia de seguridad diaria. Existen numerosos mtodos de copia de seguridad que varan en costo y efectividad. Un sitio de respaldo caliente proporciona en tiempo real de recuperacin al cambiar automticamente a un entorno completamente nuevo de forma rpida y eficiente. Para aplicaciones menos crticas, calientes y sitios de respaldofros puede ser utilizado. Estos son similares a los sitios de respaldo calientes, pero son menos costosos y eficaces. Ms comnmente, los sitios utilizan una combinacin de sitios de respaldo, balanceo de carga y alta disponibilidad. Otras estrategias de copia de seguridad comunes combinar replicacin, sombras, y copia de seguridad remota, as como los mtodos ms mundanos como respaldo en cinta o matriz redundante de discos independientes (RAID ) tecnologas. Todos son tan viable como un sitio de respaldo caliente, pero requieren ms tiempo de restauracin. Cualquier copia de seguridad fsica deben ser almacenados en un lugar remoto para ser capaz de recuperarse de un desastre. Las nuevas tecnologas hacen bveda remota electrnico una alternativa viable para copias de seguridad fsicas. Muchos otros proveedores ofrecen este servicio.

4.7.4 Plan de recuperacin

si se produce un desastre, un plan para restaurar las operaciones tan eficiente y rpidamente como sea posible debe estar en su lugar. El plan de recuperacin debe ser coordinado con el plan de copia de seguridad para asegurarse de que la recuperacin se produce sin problemas. La respuesta adecuada debe estar disponible para que sin importar en qu situacin se produce, el sitio est en funcionamiento en el tiempo acordado de recuperacin de desastres. Una prctica comn es la tasa de interrupciones de menor a crtica y tener una respuesta correspondiente. Por ejemplo, un fallo en el disco duro podra ser clasificado como un corte de Clase 2 y Clase 2 tiene una respuesta donde se reemplaza el disco y se replica con un tiempo de recuperacin de 24 horas. Esto hace ms fcil debido a la recuperacin de los recursos no se malgasten y tiempo de recuperacin de desastres se optimiza. Otro punto clave del plan de recuperacin debe resolver es qu ocurre despus de la recuperacin. Desastres menores, como fallo de disco, tienen poco impacto despus pero los desastres crticos, tales como la prdida del sitio, tienen un impacto significativo. Por ejemplo, si un sitio de respaldo caliente se usa, el plan de recuperacin debe tener en cuenta el retorno al funcionamiento normal. El nuevo hardware o posiblemente un centro conjunto de datos nuevo que tenga que ser creado. Posteriores a los desastres actividades deben llevarse a cabo rpidamente para reducir al mnimo los costos.

4.7.5 Update y prueba del proceso

debe revisar el plan de copia de seguridad y recuperacin en forma regular para asegurarse de que el plan de recuperacin se adapte a sus necesidades actuales. Yo tambin necesitan u para probar el plan de forma regular para asegurar que las

tecnologas sean funcionales y que el personal involucrado conocen sus responsabilidades. Adems de las revisiones peridicas programadas, revisar el plan de copia de seguridad y recuperacin al agregar nuevo hardware, tecnologas, o de personal.

4.8 Planificacin de la instalacin centralizada

Una de las nuevas caractersticas introducidas en WebSphere Application Server Network Deployment es la V7.0 gestor de instalacin centralizada ( CIM). Uso de la CIM simplifica enormemente la instalacin y la actualizacin de las mquinas en una clula de despliegue de red. El administrador de la celda slo tiene que instalar Network Deployment en un equipo y crear un perfil de gestor de despliegue. Todas las operaciones de la CIM relacionados estn disponibles a travs de la Consola de soluciones integradas o mediante el wsadmin. mandato IBM papel blanco Managerinstalacin centralizada para IBM WebSphere Application Server Network Deployment Versin 7.0 proporciona informacin detallada acerca de la CIM. Esto debera permitir a planificar tu entorno de informacin centralizado en consecuencia. El documento se puede encontrar en la siguiente pgina web