WebSphere Application Server - Infraestructura

4.1 Infraestructura de planificación Esta sección ofrece una visión general de las fases típicas que tienen que pasar durante un proyecto. Incluye cómo reunir los requisitos y la forma de aplicar estos requisitos a un proyecto de WebSphere Application Server. Normalmente, un nuevo proyecto se inicia con sólo un concepto. Poco se sabe acerca de los detalles específicos de aplicación, en especial su relación con la infraestructura. Su equipo de desarrollo y el equipo de infraestructura deben trabajar en estrecha colaboración para atender a las necesidades del entorno de aplicación 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 más confusión que los problemas resueltos. Por este motivo, debe tener en cuenta el tamaño de los requisitos de recopilación de equipo y tratar de mantener las reuniones lo más centrado posible. Proporcionar modelos de documentos para ser completados por los promotores, los propietarios de negocios de aplicaciones, y el equipo de experiencia del usuariocategorías:.

Trate de obtener información que cae en las siguientes ► Requisitos funcionales

Los requisitos funcionales son generalmente determinados por las empresas en el uso de la aplicación 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 tráfico, patrones de tráfico y el tamaño de la audiencia esperada.

reunión Requisitos es un proceso iterativo. Asegúrese 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, asegúrese de que las dependencias y los datos de flujos-, si la aplicación o infraestructura relacionada, están claramente documentados. Con esta lista de requisitos, usted puede comenzar a crear el primer borrador de su diseño. Target desarrollo de los diseños siguientes: ► Aplicación de diseño

para crear el diseño de su aplicación, use sus requerimientos funcionales y no funcionales para crear directrices para los desarrolladores de la aplicación sobre la forma en que su aplicación está construidatu.

► Diseño Implementación Este diseño define la infraestructura de implementación de destino en que aplicación se implementa. La versión final de este diseño de la aplicación 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 diseño de su aplicación 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 demás componentes se definen en la fase de requisitos.

Con estos dos diseños de proyectos, usted puede comenzar el proceso de la formulación de cargos de los servidores, los requisitos de red y los otros artículos relacionados con la infraestructura. Se describe en este 4.3, "Dimensionamiento de la infraestructura" en la página 106. En algunos casos, puede ser apropiado

realizar pruebas de referencia. Hay muchas maneras de realizar las pruebas de evaluación comparativa, y en 4.4, "Benchmarking" en la página 107, se describen algunos de estos métodos. 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 más detalles sobre la forma de planificar las pruebas de carga, vea 4.5, "Ajuste del rendimiento" en la página 108.

4.2 Consideraciones de diseño En las secciones siguientes se describen algunos puntos a considerar cuando se diseña un despliegue de WebSphere Application Server. Que lo más probable es que el impacto del diseño de manera significativa. Vamos a hablar con más detalle sobre:

● "Escalabilidad" en la página 96 ● "Caching" en la página 98 ● "Alta disponibilidad" en la página 99 ● "equilibrio de carga y conmutación por error-" en la página 100 ● "Recuperación de desastres" en la página 101 ● "Seguridad" en la página 102 ● "despliegue de aplicaciones" en la página 104 ● "Servicability" en la página 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 diseño de su infraestructura para ser escalable por lo tanto, significa diseñar 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 aplicación de técnicas apropiadas de escala puede mejorar la disponibilidad y el rendimiento. Técnicas 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 ● bordepresentación servidores ● web servidores de aplicaciones ● de datos servidores de ● transacciones servidores ● lógicos particiones (LPAR)

Utilice los siguientes pasos para clasificar su sitio web e identificar las técnicas 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 están diseñadas para el escalado. Es importante entender el flujo de los componentes y los volúmenes de tráfico 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 transacción. 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 línea 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 patrón de carga de trabajo para un sitio determina dónde centrar los esfuerzos de escalabilidad y que las técnicas de escalamiento que debe aplicar. Por ejemplo, un cliente de autoservicio sitio, como por ejemplo un banco en línea, tiene que centrarse en el rendimiento de la transacción y la escalabilidad de las bases de datos que contienen la información del cliente que se utiliza en las sesiones. Estas consideraciones no típicamente sería significativo para una publicación / suscripción de sitio, donde un usuario se registra para los datos que se enviarán a ellos, por lo general a través de un mensaje de correo electrónicoPublicar. 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 más afectados. Este paso implica el mapeo de las características del emplazamiento más 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 están más utilizadas por las operaciones clave de sus aplicaciones. 4. Seleccione las técnicas de escalamiento para aplicar. Cuando la recopilación de información es tan completa como puede ser, es el momento de considerar igualar técnicas de escalamiento a los componentes. Capacidad de administración, la seguridad y la disponibilidad son factores críticos en todas las decisiones de diseño. No utilice técnicas que proporcionan escalabilidad sino comprometer cualquiera de los factores antes mencionados críticos-. Elija una de las técnicas de escalamiento siguientes: Utilización de un equipo más rápido - Usando múltiples máquinas - Creación de clusters - El uso de servidores de electrodomésticos - Segmentación de la carga de trabajo - Uso de las solicitudes de lotes - La agregación de datos de los usuarios - Gestión de conexiones - Uso de técnicas de almacenamiento en caché - Uso de técnicas inteligentes de virtualización de 5. Aplicar las técnicas. Las pruebas son clave para la implementación de la aplicación exitosa. Es crucial que determinar no sólo si las técnicas 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 aplicación debe ser equilibrado. Sólo cuando se han logrado los resultados deseados si se trasladase a la producción. 6. Vuelva a evaluar. Reconocer que cualquier sistema es dinámico. La infraestructura inicial en algún 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 tráfico requerirá el examen de las configuraciones de la máquina. La escalabilidad no es una consideración vez un diseño, es parte del crecimiento del medio ambiente-.

El artículo Diseño developerWorks para Escalabilidad Una actualización proporciona una discusión detallada sobre estos pasos. Se puede acceder a la siguiente página Web: http://www.ibm.com/developerworks/websphere/library/techarticles/hipods / scalability.html Estamos ampliando algunas de las técnicas de escalamiento en el Capítulo 7, "Rendimiento, escalabilidad, y alta disponibilidad "en la página 229. 4.2.2Caching Cachinges una técnica ampliamente utilizada para mejorar el rendimiento de los entornos de servidor de aplicaciones. Si la planificación de un sitio web de alto volumen, almacenamiento en caché muy probable que sea necesario para lograr resultados satisfactorios de desempeño a un costo aceptable. WebSphere Application Server proporciona muchas características 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) según lo dispuesto por la mayoría de las implementaciones de IBM HTTP Server)

► Aplicacióncapa del servidor: ● Servicio de almacenamiento en caché dinámico dentrodel servidor de aplicaciones JVM ● del servidorproxy WebSphere

Además de las características 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 aplicación debe estar diseñado para almacenar en caché también. Por lo tanto, se sugiere el diseño de almacenamiento en caché en estrecha colaboración con el arquitecto de aplicaciones. Después de que haya terminado con el diseño de sus lugares de caché de completar el diseño de su aplicación para incluir los componentes de almacenamiento en caché. 4.2.3 Alta disponibilidad El diseño de una infraestructura de alta disponibilidad significa diseñar una infraestructura de manera que su entorno puede sobrevivir al fallo de los componentes de uno o múltiples. Alta disponibilidad implica redundancia evitando cualquier punto único de fallo en cualquier capa (red, hardware, procesos, y así sucesivamente). El número de fallar los componentes de su entorno tiene que sobrevivir sin perder el servicio depende de los requisitos para el entorno específicoinfraestructura:. 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 mayoría de los casos significa la redundancia, esto también significa que la alta disponibilidad aumentará el costo de la implementación.

No todos los servicios tiene los mismos requisitos de alta disponibilidad. Por tanto, sería una pérdida 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 reúnen dónde 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 diseño de la aplicación que se desarrolló en 4,1 , "Infraestructura de planificación" en la página 94, y determinar la importancia de este componente es la disponibilidad del servicio, y cómo una falla podría afectar la disponibilidad de su serviciolista:. ● Evalúe 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 están dispuestos a tomar para que este componente de alta disponibilidad

Considere la posibilidad de un mantenimiento regularsituaciones. Además 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 están 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 más de opción de hacer un componente de alta disponibilidad. Tienes que hacer una selección, como a los que mejor se adapte a sus necesidades

-.¿La aplicación manejar las interrupciones de una manera definidacomponente?. Consulte a los desarrolladores de aplicaciones sobre cómo trata la aplicación de un corte de un En función del componente y la situación de error, la aplicación puede necesitar un diseño específico o la recuperación de errores codificados antes de usar características de alta disponibilidad de la infraestructura

-.Dé prioridad a sus inversiones de alta disponibilidadarchivo. Decidir la aplicación de alta disponibilidad basada en la criticidad del componente y el corte de tasa esperada. Documentar cualquier desviación de la recogida de requisitos

-.Tamaño de cada componente en una forma que pueda proporcionar capacidad suficiente, incluso en caso de fallo de un componente redundantealta.

Después de que haya terminado con su diseño de alta disponibilidad, actualizar el diseño de su aplicación para incluir el características de disponibilidad. 4.2.4 Balanceo de carga y conmutación por error-Comoresultado de las consideraciones de diseño 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 cómo implementar esta redundancia para asegurar obtener el mayor beneficio de los sistemas durante las operaciones normales, y cómo va a gestionar una perfecta conmutación por error en caso de fallo de un componente. Esto introduce las siguientes técnicas para el diseño: ►Equilibrio de carga

Equilibrio de carga es la técnica de repartir la carga a través de múltiples copias de un componente para un uso óptimo de los recursos disponiblesautomáticamente.

► 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 automáticamente por el sistema y vuelve a unir de manera transparente el procesamiento de carga de trabajo.

Para el diseño de balanceo de carga y conmutación por error, lo que necesita saber cada componente de equilibrio de carga y conmutación por error de capacidades y cómo pueden ser utilizado. Dependiendo de las características que se utiliza y cómo lograr estas capacidades, se requieren hardware y software adicionales para obtener una alta disponibilidad. En un entorno de servidor WebSphere Application típico, hay una gran variedad de componentes que necesitan ser considerados en la aplicación 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 mensajería ● Back-end sirve (bases de datos, sistemas de información 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 mensajería por omisión de WebSphere es proporcionada por el administrador de aplicaciones WebSphere disponibilidad de servidores de alta densidad (HAManager) cuando utilice clústeres de WebSphere. Tenga en cuenta que el HAManager requiere almacenamiento compartido entre todos los miembros del clúster para poder conmutación por error del servicio de mensajería. Después de que haya terminado su balanceo de carga y conmutación por error discusión, actualizar el diseño de su aplicación para incluir estas características también. 4.2.5 La recuperación de desastres recuperación de desastres es un requisito diferente de alta disponibilidad. En 4.2.3, "Alta disponibilidad" en la página 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 provisión de recursos suficientes. Recuperación 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 planificación de recuperación de desastres son los siguientes: ► Objetivo de Tiempo de Recuperación

(RTO) ¿Cuántotiempo puede pasar antes de que el componente no debe estar en funcionamientoaccesible?

► Objetivo de Punto de Recuperación ¿Cuánta (RPO)pérdida 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 pérdida de datos puede ser otorgada, la RPO sería cero.

Planificación para la recuperación de desastres es una tarea compleja, y requiere de una planificación de extremo a extremo para todos los componentes del centro de datos. Para obtener información sobre WebSphere Application Server y la recuperación de desastres, consulte el artículo 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 página 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 misión crítica y las transacciones comerciales.

Por esta razón tenemos que diseñar la seguridad adecuada en nuestra infraestructura de WebSphere Application Server desde el inicio de la fase de diseño. WebSphere Application Server proporciona una infraestructura de seguridad en continua expansión y flexible que puede utilizar para hacer que el acceso a sus aplicaciones y datos más seguros. El modelo de seguridad de WebSphere Application Server se ha mejorado en la versión 7.0 mediante la adición de las siguientes características (para más información vea 12.1, "¿Qué hay de nuevo en V7.0" en la página 380):

● Soporte para múltiples dominios de seguridad ● seguridadde auditoría ● Mejoras depara la gestión de certificados ● SPNEGO Kerberos yun soporte para ● Java EE 5 Soporte de seguridadAnotaciones

Kerberosapoyo no es parte de los productos básicos, 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 planificación de una infraestructura de WebSphere Application Server. En muchos casos se encuentran los componentes reutilizables de una infraestructura de seguridad ya existentesinfraestructura:.. en cuenta cómo afectará a la seguridad de su ● Entender la política 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. ● Asegúrese de que la seguridad física suficiente en su lugar. ● Asegúrese de que los desarrolladores de aplicaciones de comprender los requisitos de seguridad y código de la aplicación correspondiente. ● Considere el registro de usuario (o registros) que va a utilizar. WebSphere Application Server V7.0 soporta múltiples registros de usuarios y múltiples dominios de seguridad. ● Asegúrese de que los registros de usuarios no están 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, asegúrese 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 demás. 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 diseño de su aplicación actual y garantizará que todo acceso posible a los sistemas está asegurada. ● Considere el nivel de auditoría requerido y la forma de ponerla en práctica. ● Considere cómo proteger los datos almacenados. Piense en la seguridad del sistema operativo y el cifrado de los datos almacenados. ● Definir una política de contraseñas, incluyendo consideraciones para el manejo de caducidad de contraseñas para los usuarios individuales. ● Considere los requisitos de cifrado para el tráfico de red. Cifrado introduce costos de los recursos generales y el aumento, por lo que utilizar el cifrado sólo en su casovencimiento:.. ● definir el cifrado (SSL) puntos finales en sus comunicaciones

► Plan de certificados y su

● Decida qué tráfico requiere certificados de una autoridad de certificación de confianza y para que el tráfico 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 gestión de los certificados. Muchas autoridades de certificación de confianza proporcionan las herramientas en línea que apoyan la gestión de certificados. Pero ¿qué pasa con los certificados autofirmados ● ¿Cómovas 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 cómo va a obtener sus certificados. Los certificados son la clave de sus datos, por lo tanto, asegúrese de que están 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 artículo WebSphere Application Server V6 avanzado endurecimiento de la seguridad Parte1, disponible en la página Web siguiente: http://www.ibm.eom/developerworks/websphere/techjournal//0512_botzum / 0512_botzuml.html

Después de haber terminado sus consideraciones de seguridad, actualizar el diseño de su aplicación para incluir todos los componentes relacionados con la seguridad .

4.2.7 Implementación de la aplicación Cuando la planificación de la infraestructura de WebSphere Application Server, no se demore pensamientos de implementación de aplicaciones hasta que la aplicación está lista para desplegarse. Iniciar esta tarea de planificación cuando se inicia el diseño de su infraestructura. La forma de implementar la aplicación afecta el diseño de la infraestructura de varias ► maneras:.Rendimiento

La forma de implementar la aplicación puede afectar al rendimiento de forma significativa. Las pruebas mostraron diferencias significativas en el rendimiento al implementar Enterprise Java Bean (EJB) módulos para el mismo servidor de aplicaciones como los componentes de cliente EJB, en comparación con el despliegue de módulos EJB en un servidor de aplicación por separado de los componentes de cliente EJB. Implementación de módulos EJB a los servidores de aplicaciones independientes, sin embargo , da mucha más flexibilidad y evita la duplicación de código.

► Número de servidores de aplicaciones

Al planear la implementación de múltiples aplicaciones en su entorno usted puede desplegar múltiples aplicaciones para el mismo servidor de aplicaciones o crear un servidor para cada aplicación. En función de la decisión que podría terminar con un mayor número de servidores de aplicaciones en tu celular. Esto significa que usted tendrá una celda más 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 comunicación Cuanto mayor sea el número de servidores de aplicaciones, mayor es la sobrecarga de comunicaciones y sistemas de gestión en su medio ambiente.

► plataformas WebSphere Application Server admite la creación de plataformas células. Esto significa que puede crear una celda que contiene servidores en múltiples plataformas. Si bien esta opción aumenta la complejidad del entorno y hace que la administración sea más complicado, le da una gran flexibilidad a la hora de la integración de componentes de software existentes.

Después de saber cómo las aplicaciones se pueden implementar, actualizar el diseño de su aplicación.

4.2.8 Servicability

Plan para las tareas de determinación y servicability problema para su entorno. La planificación de servicability incluye la planificación de las herramientas, la educación, los requisitos de disco para depuración 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 Análisis de problemas y toma de datos. Consulte las siguientes páginas Web para más información: http://www-01.ibm.com/software/support/i

Dimensionamiento de la infraestructura Después de determinar la demanda inicial y diseño de infraestructuras y técnicas 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 diseño son todavía honrado. Diseño de aplicaciones evolucionará con el tiempo, y el tamaño se suele hacer en las primeras etapas de diseño. Sin embargo, al determinar el tamaño, es importante que usted tiene una versión estática del diseño de la aplicación con la que trabajar. La mejor visión que usted tiene de diseño de la aplicación, la mejor estimación de su tamaño será. Usted tiene que considerar que las plataformas de hardware que desea utilizar. Esta decisión depende de los siguientes

● Escala de capacidades de lasde la plataforma ● plataformasWebSphere Application Server soporta el ● factores:.desempeño, la seguridad y los requisitos de alta disponibilidad de su entorno

continuación, determine el enfoque de escala: ► Escalaarriba-verticalampliación

Escala se lleva a cabo dentro de un solo sistema, por lo general en una máquina multi-procesador. 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 número de máquinas. El escalado se hace generalmente para mejorar la alta disponibilidad mediante la limitación 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 máquinas. Si decide utilizar la escala el planteamiento tenga en cuenta que su diseño 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 más precisa es la de entrada, mejores serán 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 transacción. Los cálculos basados en este se realizan para determinar el número estimado de máquinas y transformadores de su aplicación se requieren. Si su empresa cuenta con un equipo de experiencia del usuario, que podrían haber documentado los estándares para un tiempo de respuesta típico de que su nuevo proyecto tiene la obligación de cumplir. Si necesita una estimación más precisa de los requisitos de hardware y ya tiene su aplicación, considere el uso de un los servicios de referencia se tratan en 4.4, "Benchmarking" en la página 107. Sobre la base de su estimación, es posible que tenga que actualizar el diseño de la implementación para todos sus ambientes planeados. Los cambios en el entorno de producción 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 integración y el entorno de desarrollo son funcionalmente equivalentes. Asegúrese para validar el apresto con una prueba de carga antes de iniciar la producción.

4,4Benchmarking Benchmarkinges el proceso utilizado para determinar la capacidad de un entorno de aplicación a través de pruebas de carga. Esta determinación 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 después de cada lanzamiento o actualización de un componente. Estos clientes suelen tener bien desarrolladas entornos de prueba de aplicaciones y equipos dedicados a la evaluación comparativa. Para aquellos que no lo hacen, otras alternativas como el centro de pruebas de IBM están disponibles. También hay otras compañías 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 montón de problemas de rendimiento y ayudar a mejorar la calidad del código de la aplicación, así como la solidez del medio ambiente en general.

Test Center de IBM IBM Global Services ofrece la gestión del rendimiento, pruebas y servicios de escalabilidad. Este equipo va a venir en el sitio y evaluar el desempeño general del sitio. Esta investigación es una plataforma neutral. Las ofertas incluyen, pero no están limitados a los siguientes servicios:

● Servicios de ensayo y escalabilidad para redes TCP / IP ● de prueba y servicios de escalabilidad para el sitio Webestrésanálisis ● Performance Engineeringyde procesos de pruebaConsulting ● Pruebas de Rendimiento yValidación ● Afinaciónde rendimiento y optimización 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 documentación 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 más 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 producción, es necesario estar seguro de que el medio ambiente puede manejar la carga de usuarios. Los problemas de rendimiento son, con mucho, la más visible para el usuario problema que usted pueda tener. La mayoría de los usuarios están dispuestos a aceptar pequeños problemas de funcionamiento cuando un sistema es lanzada al mercado, pero los problemas de rendimiento son inaceptables para la mayoría de usuarios y afectan a todos los que trabajan en el sistema. Asegúrese de realizar las pruebas de carga que representan una carga de usuarios realista contra el sistema. 4.5.1 cuestiones de diseño de aplicaciones Muchos de los problemas de funcionamiento que no puede solucionar mediante el uso de más hardware o cambiar los parámetros 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 programación del proyecto

Nota:. Se sugiere el desarrollo de aplicaciones para utilizar las técnicas de aplicación 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 más esfuerzo y dinero para corregir los problemas después de que se produjo en la producción 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 diseño de su aplicación mucho más temprano, lo que resulta en un menor número de problemas al utilizar la aplicación en el entorno de producción.

4.5.2 Entender sus necesidades, sin una clara comprensión de sus necesidades, usted no tiene ninguna meta para sintonizar en contra. Es importante cuando se hace el ajuste de rendimiento contar con objetivos específicos los siguientes:

● Transacciones por segundo ● Rendimiento ● Un marco de tiempo máximo, para aplicaciones de estilo de lote ● máximo los recursos utilizados

no pierdas tiempo afinando el rendimiento de un sistema que era de tamaño 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

configuración del entorno de prueba 4.5.3 Al ejecutar pruebas de rendimiento, siga estos consejos generales: ► Ejecutar las pruebas en un entorno de producción-como.

El uso de un medio ambiente que es lo más cercano posible al entorno de producción le permite extrapolar los resultados de las pruebas para el entorno de producción. Si usted está comenzando con un nuevo entorno utilizar el entorno de la futura producción para las necesidades de su prueba antes de publicarla.

► Acceso exclusivo para el medio ambiente para la prueba. Asegúrese de que nadie está utilizando los sistemas de prueba y que no se están ejecutando procesos en segundo plano que consumen más recursos que lo que se encuentra en producción. Por ejemplo, si la intención es poner a prueba el rendimiento durante la copia de seguridad de base de datos, asegúrese de que la copia de seguridad está en marcha.

► Uso de opciones de monitorización. 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 depuración

El objetivo es identificar posibles cuellos de botella o las razones de los problemas. El nivel de depuración se detalla y utilizará recursos adicionales, por lo general afectan a los resultados de las pruebas-.

de control de producción Después de identificar y resolver problemas de rendimiento con el seguimiento de depuración, realice una prueba con el mismo conjunto de opciones de control que se utilizarán posteriormente en el entorno productivo. Con esta opción, 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 después de cada prueba para ver si hay algún patrón inusual. Si el entorno de destino está utilizando una infraestructura compartida, asegúrese de que el componente compartido está llevando a cabo bajo la carga proyectada compartido.

► aislar el tráfico de red tanto como sea posible. Uso de interruptores, rara vez hay una circunstancia en la que el tráfico procedente de un servidor excesos de un puerto de otra. Es posible, sin embargo, a los puertos de inundación utilizado para el encaminamiento de la red a otras redes o incluso el esqueleto de interruptor para el tráfico pesado. Asegúrese de que la red aísla el entorno de prueba tanto como sea posible antes de la partida, ya que la degradación 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. Asegúrese de que tiene suficiente información sobre pruebas disponiblessiguientes:.

4.5.4 Factores de carga Los factores más importantes que determinan cómo 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 más importantes en función en el tipo de sitio que se está desarrollando. tasa de Solicitud La tasa de solicitud representa el número de solicitudes por unidad de tiempo. En entornos basados en Web esto es principalmente expresada en número 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 simultáneos,el de usuarios concurrentes númeroexpresa el número de usuarios al mismo tiempo que solicitan servicio de su entorno en un punto en el tiempo. Este número de usuarios que realmente está disparando peticiones al sistema en un punto dado de tiempoexisten:. en contraste a los usuarios simultáneos que ► usuarios

usuariosActive expresa todos los usuarios actualmente utilizando los recursos (por ejemplo, en forma de datos de la sesión) en su entorno. También incluye a los usuarios que están leyendo la respuesta, la introducción de datos, etc.

Usuarios ►Nombrados los usuarios con nombre usuariossonque se definen en el medio ambiente en general. Esto suele ser un número grande en comparación con el número de usuarios concurrentes.

Los patrones de uso en este punto en el proyecto, es importante que tengas en cuenta cómo los usuarios van a utilizar el sitio. Es posible que desee utilizar los casos de uso que los desarrolladores se definen por su diseño de la aplicación como un insumo para construir sus patrones de uso. Esto hace que sea más fácil de construir los escenarios después de que la prueba de carga se utilizanfactores:. patrones de uso integrado por los siguientes ● Los casos de uso modelan como hacer clic a través de los flujos de páginas ● pesos aplicados a sus casos de uso de pesos de combinación con las corrientes clic es importante porque muestra número de usuarios que se espera en la que los componentes de la aplicación, y donde se generan carga. Después 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 través del catálogo que viceversa. Estos supuestos también 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. Asegúrese de que los casos de uso más comunes son aquellos en los que la mayor parte del trabajo se lleva a cabo la optimización del rendimiento. Para utilizar esta información más 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 producción tuning Aquí es donde se aplica todo el rendimiento, escalabilidad y alta disponibilidad en la producción. Ajuste del sistema es un proceso iterativo que implica la optimización de los parámetros de WebSphere para adaptarse a su entorno de ejecución

Importante:. Para utilizar la sintonización en el entorno de producción, tener la versión final del código que se ejecuta. Esta versión debería haber pasado las pruebas de rendimiento en el

entorno de integración antes de cambiar ningún parámetro de WebSphere en el sistema de producciónestándar:...

Cuando se cambia un entorno de producción, utilice algunas de las prácticas

● Cambie sólo un parámetro a la vez ● Documentar todos los cambios ● de comparación prueba corre a varios la línea de base.

Cambios entre las ejecuciones de prueba no deberán diferir en más de un pequeño porcentaje de impedir la introducción de los nuevos problemas que usted pueda necesitar para resolver antes de continuar afinación. Tan pronto como termine afinar sus sistemas de producción, aplicar la configuración a sus entornos de prueba para asegurarse de que son similares a la producción. Planee volver a ejecutar las pruebas allí para establecer nuevas bases de referencia sobre estos sistemas y ver cómo estos cambios afectan al rendimiento. Tenga en cuenta que a menudo sólo tienen una oportunidad para hacerlo bien. Por lo general, tan pronto como usted está en producción con el sistema, no se puede ejecutar pruebas de rendimiento en este entorno más, simplemente porque usted no puede tomar el sistema de producción en línea para realizar más pruebas de rendimiento. Si un sistema de producción está siendo probado, es probable que el sistema está funcionando en una posición muy degradado, y que ya han perdido la mitad de la batalla

Nota:. Debido a que es raro utilizar un sistema de producción 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.

Después de completar sus pruebas de rendimiento primero y ajuste de los parámetros WebSphere, evaluar sus resultados y compararlos con los objetivos para ver cómo 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, asegúrese de que usted ha planeado para el crecimiento y de que están cumpliendo todos los objetivos de rendimiento. Después de eso, se sugiere documentar sus hallazgos en un informe de la optimización 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 aplicación. Estos datos son esenciales al agregar réplicas adicionales de algunos componentes en el sistema, ya que necesitan estar configurados con la misma configuración que utilizan los recursos actuales.

► Rendimiento es más lento de lo necesario. Si el rendimiento de las aplicaciones es algo más lento de lo esperado, y ya han hecho todo lo posible aplicación y puesta a punto de WebSphere parámetro, es posible que tenga que agregar más hardware (por ejemplo, aumentar la memoria, los procesadores de actualización, etc) a los componentes de cuello de botella en su entorno. A continuación, ejecute de nuevo las pruebas. Verifique con los equipos adecuados que no había perdido los cuellos de botella en el flujo general del sistemasiguientes:..

► Rendimiento es significativamente más lento que requiere en este caso, se debe empezar de nuevo con su tamaño y haga las preguntas

● ¿Sabía usted que subestimar ninguna de las características de la aplicación durante su tamaño inicial? Si es así, ¿por qué? ● ¿Se subestiman el tráfico y número de usuarios / visitas en el sitio? ● ¿Sigue siendo posible cambiar partes de la aplicación para mejorar el rendimiento? ● ¿Es posible obtener recursos adicionales?

Después de responder a estas preguntas, usted debe tener una mejor comprensión sobre el problema que usted enfrenta. Su mejor apuesta es analizar la aplicación 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 Planificación la vigilancia a dela mayoría 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 página 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 tramitación 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 Análisis Ambiental para el seguimiento de la planificación cuidadosa para el seguimiento es esencial y debe comenzar con un análisis 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 visión 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 ¿Cuáles

● preguntas:son los posibles estados de los componentes y cómo puedes recuperar ● Cuál es el impacto de cada uno de los estados posibles del componente puede tener locontrolar? ● que los atributos específicos del componente se puede ● ¿Paracada atributo se puede controlar, definir los siguientes

● valores: ¿Quévalores de atributo (o rango de valores de atributos) muestran un estado normal del componente ● Cuáles son los valores de atributo (o rango de valores de atributos) muestran una situación que requiere la atención del administrador (nivel de advertencia)? ● Qué valores de atributo (o rango de valores de atributos) muestran una condición crítica para el componente y requieren una acción 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 supervisión, es necesario utilizar algún 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 también. Agentes de controlen función del software de monitoreo en uso, agentes de supervisión para ciertos componentes estén disponibles. De lo contrario, la mayoría 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 solución de monitorización. Asegúrese de que todos los requisitos no funcionales para su infraestructura se aplican a estos sistemas también. 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 supervisión y múltiples soluciones para diferentes propósitos. Supervisión de la red de monitoreo de red cubre toda la infraestructura de red como switches, firewalls, routers, etc. También debe supervisar la disponibilidad de todas las vías de comunicación, incluidas las vías de comunicación redundantes. Monitoreo del sistema operativo más 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 aplicación 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 específico para el middleware que proporciona el entorno de ejecución de la aplicación. WebSphere Application Server ofrece varias interfaces que permiten el control de su infraestructura de servidor de aplicaciones. Muchos productos de monitorización 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 Propósito 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 interacción 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 más recursos. Asegúrese de que la configuración de monitorización no causa efectos inaceptables para el medio ambiente. Cuanto más monitorear, y cuanto menor sea el intervalo entre los ciclos de monitorización, más rápido se puede determinar algo fuera de lo común. Pero cuanto más monitorear, y cuanto menor sea el intervalo entre los ciclos de monitorización, 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. Además del impacto en el rendimiento, es necesario asegurarse de que cualquier problema en su infraestructura de monitorización no afectan su ambiente. Monitoreo, incluso si hay algo mal en la infraestructura de supervisión, no debe ser la causa de cualquier interrupción del servicio.

4.6.3 Alerta yde resolución 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. ¿Cuál es el uso

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

● Quién es alertado por qué evento ● a:???¿Cuáles son los tiempos de respuesta requeridos ● ¿Cómo serán los responsables sean alertados ● ¿Cómo va a evitar alertas repetidas por los mismos hechos ● ¿Cómo alertas y la resolución de la de las alertas se documentará ● ¿Quiénhará un seguimiento de las alertas y resolución de problemas? ● ¿Quién está a cargo de la alerta hasta que se resuelva definitivamente, ● quién llevará a cabo el análisis de causa raíz para evitar la recurrencia de la alerta?

alerta es sólo una primera parte de su gestión de incidentes y problemas. Para más información y más detalles sobre el incidente y la administración de problemas se refieren a las páginas de ITIL ® en la página 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 aplicación es nueva, probar todas las alertas único de vigilancia y asegúrese de que el monitoreo detecta cada condición de su sistema correctamente. No suspenda la prueba cuando se ve una situación de vigilancia levantada. Pon a prueba todo el proceso, incluida la alerta y gestión de incidentes y garantizar que las condiciones se restablecen automáticamente tan pronto como la situación ha vuelto a la normalidad.

4.7 Planificación de copia de seguridad y recuperación

En general, el hardware y el software es confiable, pero a veces pueden ocurrir errores y daños una máquina, dispositivo de red, software, configuración, o más importante, los datos empresariales. No hay que subestimar el riesgo de un error humano que pudiera conducir a daños. Es importante planear para tales casos. Hay una serie de etapas para crear un plan de copia de seguridad y recuperación, lo que se discute en las siguientes secciones.

4.7.1 Análisis de riesgos El primer paso para crear una copia de seguridad y plan de recuperación consiste en realizar un análisis integral de riesgos. El objetivo es descubrir qué áreas son las más críticas y que tienen el mayor riesgo. Es importante identificar qué procesos de negocio son los más importantes y se priorizan en consecuencia.

4.7.2 estrategia de recuperación Cuando las áreas críticas han sido identificados, desarrollar una estrategia para la recuperación de esas áreas. Hay numerosos copia de seguridad y estrategias de recuperación disponibles que varían en el tiempo de recuperación y el costo. En la mayoría de los casos, el coste aumenta a medida que disminuye el tiempo de recuperación. La clave para la estrategia apropiada es encontrar el equilibrio adecuado entre el tiempo de recuperación y el costo. El impacto en el negocio es el factor determinante en la búsqueda del equilibrio adecuado. Críticas para el

negocio procesos necesitan tiempo de recuperación rápida para minimizar las pérdidas de negocios. Por lo tanto, los costos de recuperación son mayores.

4.7.3 plan de copia

de seguridad con la estrategia de recuperación, un plan de copia de seguridad tiene que ser creado para manejar las operaciones de copia de seguridad diaria. Existen numerosos métodos de copia de seguridad que varían en costo y efectividad. Un sitio de respaldo caliente proporciona en tiempo real de recuperación al cambiar automáticamente a un entorno completamente nuevo de forma rápida y eficiente. Para aplicaciones menos críticas, calientes y sitios de respaldofríos puede ser utilizado. Estos son similares a los sitios de respaldo calientes, pero son menos costosos y eficaces. Más comúnmente, los sitios utilizan una combinación de sitios de respaldo, balanceo de carga y alta disponibilidad. Otras estrategias de copia de seguridad comunes combinar replicación, sombras, y copia de seguridad remota, así como los métodos más mundanos como respaldo en cinta o matriz redundante de discos independientes (RAID ) tecnologías. Todos son tan viable como un sitio de respaldo caliente, pero requieren más tiempo de restauración. Cualquier copia de seguridad física deben ser almacenados en un lugar remoto para ser capaz de recuperarse de un desastre. Las nuevas tecnologías hacen bóveda remota electrónico una alternativa viable para copias de seguridad físicas. Muchos otros proveedores ofrecen este servicio.

4.7.4 Plan de recuperación si se produce un desastre, un plan para restaurar las operaciones tan eficiente y rápidamente como sea posible debe estar en su lugar. El plan de recuperación debe ser coordinado con el plan de copia de seguridad para asegurarse de que la recuperación se produce sin problemas. La respuesta adecuada debe estar disponible para que sin importar en qué situación se produce, el sitio está en funcionamiento en el tiempo acordado de recuperación de desastres. Una práctica común es la tasa de interrupciones de menor a crítica y tener una respuesta correspondiente. Por ejemplo, un fallo en el disco duro podría 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 recuperación de 24 horas. Esto hace más fácil debido a la recuperación de los recursos no se malgasten y tiempo de recuperación de desastres se optimiza. Otro punto clave del plan de recuperación debe resolver es qué ocurre después de la recuperación. Desastres menores, como fallo de disco, tienen poco impacto después pero los desastres críticos, tales como la pérdida del sitio, tienen un impacto significativo. Por ejemplo, si un sitio de respaldo caliente se usa, el plan de recuperación 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 rápidamente para reducir al mínimo los costos.

4.7.5 Update y prueba del proceso

debe revisar el plan de copia de seguridad y recuperación en forma regular para asegurarse de que el plan de recuperación se adapte a sus necesidades actuales. Yo también necesitan u para probar el plan de forma regular para asegurar que las

tecnologías sean funcionales y que el personal involucrado conocen sus responsabilidades. Además de las revisiones periódicas programadas, revisar el plan de copia de seguridad y recuperación al agregar nuevo hardware, tecnologías, o de personal.

4.8 Planificación de la instalación centralizada Una de las nuevas características introducidas en WebSphere Application Server Network Deployment es la V7.0 gestor de instalación centralizada ( CIM). Uso de la CIM simplifica enormemente la instalación y la actualización de las máquinas en una célula de despliegue de red. El administrador de la celda sólo tiene que instalar Network Deployment en un equipo y crear un perfil de gestor de despliegue. Todas las operaciones de la CIM relacionados están disponibles a través de la Consola de soluciones integradas o mediante el wsadmin. mandato IBM papel blanco Managerinstalación centralizada para IBM WebSphere Application Server Network Deployment Versión 7.0 proporciona información detallada acerca de la CIM. Esto debería permitir a planificar tu entorno de información centralizado en consecuencia. El documento se puede encontrar en la siguiente página web