Exportar (0) Imprimir
Expandir todo

Creación de una arquitectura y estrategia de alta disponibilidad para SharePoint 2013

 

Se aplica a: SharePoint Server 2013, SharePoint Foundation 2013

Última modificación del tema: 2013-12-18

Resumen: aprenda a combinar la arquitectura de la granja de servidores y la tecnología para crear un entorno de alta disponibilidad en una sola granja de servidores de SharePoint 2013.

Un estrategia de alta disponibilidad es un requisito importante para un entorno SharePoint 2013 de producción. Una estrategia de un extremo a otro incluye los procesos operativos, la gobernanza de la plataforma, la arquitectura y las soluciones técnicas. Este artículo se centra en los aspectos arquitectónicos y técnicos de alta disponibilidad. En la guía se explican los elementos de diseño específicos de SharePoint y las opciones técnicas que determinarán la estrategia de alta disponibilidad.

NotaNota:
La alta disponibilidad y la recuperación ante desastres no son lo mismo. Aunque existe un solapamiento en la planeación y las soluciones, son subconjuntos de continuidad empresarial. El objetivo de la alta disponibilidad es proporcionar resistencia dentro del centro de datos principal y tiempos de inactividad planeados. El objetivo de la recuperación ante desastres es permitir a una organización reanudar sus operaciones informáticas en un centro de datos secundario cuando se produce un desastre en el centro de datos principal a causa del cual la infraestructura queda inutilizable. Para más información sobre la recuperación ante desastres para SharePoint 2013, vea Elegir una estrategia de recuperación ante desastres para SharePoint 2013.

En este artículo:

La alta disponibilidad se usa normalmente para describir la capacidad de un sistema de seguir funcionando y proporcionando recursos a sus usuarios cuando se produce un error en una o varias de las siguientes categorías en un dominio de errores: hardware, software o aplicación. El nivel de disponibilidad se expresa como medida del porcentaje de tiempo que un sistema está operativo de manera continuada para admitir funciones empresariales. El nivel requerido de disponibilidad varía entre las organizaciones. Aunque este requisito también puede variar entre unidades de negocio, un contrato de nivel de servicio es para toda la organización como una sola unidad. Des del punto de vista de los usuarios, una granja de servidores UNRESOLVED_TOKEN_VAL(SharePointAll_1st_NoVer) está disponible cuando los usuarios pueden acceder a la granja de servidores y usar las características y los servicios que necesitan para realizar su trabajo.

Una granja de servidores SharePoint de alta disponibilidad tiene los siguientes objetivos y características:

  • El diseño de la granja de servidores reduce los puntos de error potenciales. Puesto que es improbable que se puedan eliminar todos los puntos de error, la estrategia general debe abarcar cómo se debe responder en el evento de un error.

  • Los eventos de conmutación por error son ininterrumpidos y tienen un efecto mínimo en las actividades del usuario.

  • La granja de servidores continúa funcionando a una capacidad reducida en lugar de fallar completamente.

  • La granja de servidores es resistente. Los incidentes que afectan al servicio ocurren con poca frecuencia y, en caso de hacerlo, se realizan las acciones necesarias de forma puntual y eficaz.

Antes de crear una arquitectura y estrategia realística y económica de alta disponibilidad para el entorno SharePoint, se deben definir y cuantificar los objetivos de disponibilidad. Estos objetivos reflejan en qué medida la organización depende de SharePoint 2013 y cómo una pérdida del servicio afectaría a las operaciones de la organización. El efecto de la pérdida del servicio depende de la naturaleza de la pérdida (total o parcial), así como de la duración de la misma.

La pérdida de ingresos se identifica normalmente como el resultado principal de una reducción o una pérdida total del servicio, especialmente para las empresas que llevan a cabo negocios online. Sin embargo, otras consecuencias menos visibles pueden resultar igualmente perjudiciales para la organización. Por ejemplo, se puede experimentar una pérdida de confianza por parte de los asociados, proveedores o clientes, una disminución del respeto a la marca corporativa, así como problemas legales.

Una estrategia de alta disponibilidad adecuada debe reflejar las necesidades específicas de la organización. Además, debe proporcionar un equilibrio óptimo entre los requisitos del negocio, los contratos de nivel de servicio de TI y la disponibilidad de soluciones técnicas, capacidades de soporte de TI y costes de infraestructura.

Después de identificar los requisitos de disponibilidad de la organización, se puede empezar a crear un diseño y una estrategia de alta disponibilidad para reducir el riesgo de tiempos de inactividad y reducción de las operaciones. Los profesionales de TI que diseñan e implementan sistemas altamente disponibles usan los siguientes principios como guía para cumplir sus objetivos:

  • Eliminar los puntos de error individuales para cada dominio de error y para todo el sistema en cada nivel posible (sistema operativo, software y aplicación SharePoint).

    NotaNota:
    Un dominio de error proporciona el ámbito y el límite de un punto de error físico. En la edición de marzo de 2011 de la revista IEEE Computer Magazine se proporciona esta definición: "Un dominio de error es un conjunto de componentes de hardware (equipos, conmutadores, etc.) que comparten un único punto de error."
    Para obtener más información sobre los dominios de error y los dominios de actualización, vea el artículo sobre el dominio de error y el dominio de actualización de Windows Azure explicados para profesionales de TI.
  • Implementar sistemas muy rápidos de detección, aislamiento y resolución.

NotaNota:
Un contrato de nivel de servicio es un contrato negociado entre los proveedores de servicio de TI (un grupo de TI interno o un proveedor externo) y los representantes de los usuarios. Un contrato de nivel de servicio se usa para identificar y cuantificar los servicios y el soporte necesarios que el proveedor proporcionará. Los contratos de nivel de servicio son claros, específicos y precisos para evitar malentendidos sobre las expectativas de los proveedores y los usuarios. La claridad y la precisión son importantes porque los contratos de nivel de servicio normalmente especifican importantes penalización financieras en las que se implican a proveedores de servicios de terceros.

La alta disponibilidad y la tolerancia a errores no son lo mismo. Una definición de la alta disponibilidad es importante porque la tolerancia a errores se usa con frecuencia como sinónimo para describir cómo se implementa la alta disponibilidad.

Las soluciones de alta disponibilidad son de ámbito amplio y proporcionan un conjunto de recursos compartidos en todo el sistema que se integran para proporcionar los servicios necesarios predefinidos. La solución usa diferentes combinaciones de hardware y software estándar de la industria para minimizar el tiempo de inactividad y restaurar los servicios cuando el sistema o parte del sistema falla.

Una solución de tolerancia a errores se centra en el hardware y usa hardware especializado para detectar errores y conmutar de forma instantánea a un componente de hardware redundante. Este componente puede ser un procesador, una tarjeta de memoria, un sistema de alimentación, un subsistema E/S o un subsistema de almacenamiento. El conmutador a un componente redundante proporciona un alto nivel de servicio.

Un análisis de costos y beneficios de las soluciones de tolerancia a errores y de las soluciones de alta disponibilidad permite a las organizaciones crear una estrategia efectiva para cumplir los objetivos de disponibilidad de su granja de servidores SharePoint. Normalmente existen desventajas de costes entre ambas soluciones. Para más información, vea el artículo sobre la evaluación de soluciones de alta disponibilidad frente a soluciones de tolerancia a errores.

La disponibilidad se mide en relación con ser operativo el 100 % del tiempo o con no estar nunca inactivo. La medida común de la disponibilidad en el mundo de las TI se expresa como un número de 9s, que va de un nueve (90 %) a cinco nueves (99,999 %), que es el ideal. La medida según el número de nueves es el porcentaje de tiempo que un sistema determinado está en ejecución, funcionando o disponible para los usuarios.

NotaNota:
El tiempo activo se usa frecuentemente como sinónimo de disponibilidad. Sin embargo, puede llevar a malentendidos, ya que un sistema informático puede estar en ejecución pero no ser capaz de proporcionar los servicios y la funcionalidad que los usuarios necesitan.

El porcentaje de disponibilidad se calcula mediante la fórmula x = (n - y) * 100/n.

  • x es el porcentaje

  • n es el número total de minutos en un mes natural determinado (30 días)

  • y es el número de total de minutos que un sistema o servicio no está disponible

Como se puede ver en la tabla siguiente, en la que se correlaciona el porcentaje de disponibilidad con los equivalentes en tiempo del calendario, es difícil lograr cinco 9s de disponibilidad. Este nivel de disponibilidad también resulta costoso y complejo y, en algunos casos, conlleva riesgos. Para más información sobre los cinco 9s, lea la publicación de Vijay Gill sobre la cantidad de nueves y la publicación de Sean Hull sobre el mito de los cinco nueves y por qué la alta disponibilidad está sobrevalorada.

NotaNota:
Tres 9s de disponibilidad es la norma para la mayoría de empresas que utilizan granjas de servidores SharePoint en su centro de datos. Este nivel de disponibilidad también es típico para una granja de servidores SharePoint implementada en un entorno hospedado o en la nube.

Correlación del % de disponibilidad con el tiempo de inactividad del calendario

Porcentaje de disponibilidad aceptable Tiempo de inactividad por día Tiempo de inactividad por mes Tiempo de inactividad por año

90 (un nueve)

144,00 minutos

72 horas

36,5 días

99 (dos nueves)

14,40 minutos

7 horas

3,65 días

99,9 (tres nueves)

86,40 segundos

43 minutos

8,77 horas

99,99 (cuatro nueves)

8,64 segundos

4 minutos

52,60 minutos

99,999 (cinco nueves)

0,86 segundos

26 segundos

5,26 minutos

Aunque no se tratan en este artículo, algunos de los aspectos siguientes de un contrato de nivel de servicio deben reflejarse en un diseño de alta disponibilidad.

Definición y ámbito de la disponibilidad

No se puede crear un entorno para disponibilidad o negociar un contrato de nivel de servicio hasta que se haya definido la disponibilidad. Debe ser una medida de la capacidad de los usuarios para completar las tareas habituales que su trabajo requiere y utilizar las funciones y los servicios que UNRESOLVED_TOKEN_VAL(SharePointAll_1st_NoVer) proporciona. Las cargas de trabajo SharePoint que una organización utiliza determinan esta definición y el ámbito de disponibilidad. Los requisitos de carga de trabajo varían de un cliente a otro y se basan en las necesidades específicas de cada organización, las funciones que proporciona la granja de servidores y el perfil de los usuarios de la granja.

Exclusiones de los cálculos de disponibilidad

Las exclusiones de disponibilidad son tan importantes para el diseño de la disponibilidad como lo son para un contrato de nivel de servicio. Cada sistema requiere un mantenimiento rutinario. El tiempo de inactividad o los niveles reducidos de servicio planeados no forman parte de los cálculos de disponibilidad. Las exclusiones típicas son horas de mantenimiento programadas y tiempos de inactividad planeados para actividades como poner un virus en cuarentena o responder a una amenaza de la seguridad.

Métricas del tiempo de inactividad

En la tabla "Correlación del % de disponibilidad con el tiempo de inactividad del calendario" anterior, se identifica el tiempo de inactividad para cada 9 de disponibilidad. Las siguientes medidas se utilizan para calcular la disponibilidad:

  • Tiempo medio entre errores (MTBF): el tiempo previsto entre dos errores consecutivos para un sistema reparable.

  • Tiempo medio hasta el error (MTTF): el tiempo previsto hasta el error para un sistema que no se puede reparar.

  • Tiempo medio para la reparación o el reemplazo (MTTR): el tiempo previsto para reparar o reemplazar un componente fallido.

La fórmula siguiente calcula la disponibilidad: Disponibilidad = MTTF / (MTTF + MTTR). Se puede usar esta fórmula para calcular la disponibilidad total y mejorarla mediante el uso de componentes de hardware y software más confiables para incrementar el MTTF y reducir el MTTR.

La relación del rendimiento con la disponibilidad

El rendimiento no está aislado de la disponibilidad. Los proveedores de servicios y los consumidores definen puntos de referencia de rendimiento cuantificables para los niveles de servicio cuando un sistema se ejecuta bajo condiciones normales. Sin embargo, se reduce la disponibilidad cuando un evento extraordinario afecta significativamente al rendimiento hasta dejar el sistema básicamente inutilizable, es decir que la granja de servidores no está disponible. A continuación se indican ejemplos típicos de eventos extraordinarios:

  • Ataques por denegación de servicio en servidores web de orientación pública

  • Consultas mal formuladas que utilizan recursos del servidor de bases de datos o transacciones de bases de datos que bloquean tablas

  • Errores de red de área extensa (WAN) o elevada latencia de la red causada por eventos en otros ubicaciones

A medida que más organizaciones se pasan a granjas de servidores SharePoint distribuidas geográficamente o a entornos hospedados, la latencia de la red es extremadamente importante para planificar la disponibilidad.

Un proceso que implemente la alta disponibilidad es una de las inversiones más caras para una granja de servidores SharePoint. A medida que aumenta el nivel de disponibilidad y el número de sistemas que se desean hacer altamente disponibles, también aumenta la complejidad y el coste de una solución de disponibilidad. Los costes siguientes forman parte normalmente de una inversión en alta disponibilidad:

  • Componentes de infraestructura adicionales, como adaptadores de red, conmutadores y suministro eléctrico con fines de redundancia.

  • Hardware, software o licencias de software adicionales para admitir varios roles de la granja de servidores que proporcionan una carga de trabajo redundante en toda la arquitectura de la granja de servidores.

  • Hardware de repuesto para reemplazar el equipo dañado.

    Aunque es una práctica común preparar equipos de repuesto en distintos estados de preparación para usar para el mantenimiento rutinario o para reemplazar un servidor dañado, la inversión es para hardware que permanece inactivo.

    NotaNota:
    Los avances en la tecnología de virtualización permiten a las organizaciones usar equipos virtuales como repuestos fríos, templados o calientes. Los equipos virtuales pueden ser adecuados para proporcionar la misma funcionalidad. La virtualización puede proporcionar flexibilidad y rentabilidad. Sin embargo, debe verificarse que un equipo virtual tiene la capacidad para tratar la misma carga que el equipo físico al que va a reemplazar.
  • Mayores costes de soporte y mantenimiento en proporción al nivel de disponibilidad y a las soluciones usadas para cumplir los requisitos de disponibilidad.

  • Cambios anticipados en la granja de servidores, como el escalado horizontal. Cuando se escala una granja de servidores horizontalmente, la solución de disponibilidad debe ser capaz de reflejar todos los cambios en la topología de la granja de servidores. Probablemente se incrementen los costes.

  • Un sistema robusto de detección y alerta que proporciona una detección rápida de errores. Este sistema puede usar las herramientas de detección de errores existentes y puede incluir servicio de mantenimiento y herramientas de alerta como System Center Operations Manager.

  • Costes de integración o personalización necesarios para implementar la alta disponibilidad en la granja de servidores o para cumplir requisitos de centros de datos más amplios.

Evalúe el coste de una mayor disponibilidad en el contexto de sus necesidades empresariales principales. En muchos casos, no todas las unidades organizativas requieren el mismo nivel de disponibilidad. Considere varios niveles de disponibilidad para diferentes sitios, servicios o granjas de servidores.

Con referencia a la tabla "Correlación del % de disponibilidad con el tiempo de inactividad del calendario", cinco 9s de disponibilidad significa que durante el curso de un año el sistema solo está inactivo durante 5,26 minutos. Aunque se puede lograr este nivel de disponibilidad, el coste es prohibitivo para muchas organizaciones. Una decisión clave es determinar el punto en el que una inversión en un nueve adicional de disponibilidad no proporciona ninguna ventaja de los costes en relación con el efecto de un error.

En la siguiente ilustración se muestra cómo distribuir y configurar diferentes partes de un entorno SharePoint para aumentar la disponibilidad en una granja de servidores. Este ejemplo también muestra cómo la redundancia permite solucionar dominios de error.

NotaNota:
El ejemplo no es completo. Por ejemplo, no muestra todos los dominios de error ni todo el hardware de tolerancia a errores.

Ejemplos de redundancia en una topología de granja de servidores para tratar puntos de error

Un ejemplo de granja de servidores en el que se muestra cómo los roles y servicios redundantes se utilizan para tratar puntos únicos de errores.

Con referencia a la topología de la ilustración anterior, tenga en cuenta lo siguiente:

  • Los servidores de la granja de este ejemplo pueden ser equipos físicos o máquinas virtuales que se implementan en servidores host Hyper-V. El principio de identificación y respuesta a puntos de error se aplica a ambos tipos de entorno.

  • Cuatro servidores (W1-W4) se dedican a servir contenido y esta redundancia incrementa la disponibilidad si se produce un error en uno o varios servidores. Este nivel de redundancia también permite a la granja de servidores continuar con las operaciones mientras se aplican actualizaciones de software.

  • Cuatro servidores de aplicación (A1-A4) incrementan la disponibilidad para los servicios de la granja de servidores y componentes de aplicación específicos, como la búsqueda. La búsqueda de roles y componentes es redundante. Para más información sobre la disponibilidad de la búsqueda, consulte Escalar búsquedas para los sitios de Internet en SharePoint Server 2013

  • Los servidores de bases de datos de la granja de servidores son redundantes y la alta disponibilidad de las bases de datos se puede lograr mediante el reflejo de bases de datos y los clústeres.

  • En un entorno virtual, las máquinas virtuales se colocan en servidores host Hyper-V independientes para eliminar un único punto de error. Este enfoque para la colocación de las máquinas virtuales sigue las instrucciones de prácticas recomendadas para la disponibilidad y el rendimiento.

  • El servidor de bases de datos principal (con la etiqueta 1) y el bastidor 2 (con la etiqueta 2), que contiene dos de los equipos host de virtualización, se identifican como dominios de error para mostrar cómo la granja de servidores y la infraestructura se pueden visualizar como una colección de dominios de error. Esto muestra cómo se puede realizar un análisis detallado del entorno para desarrollar una estrategia global y un análisis de costes y beneficios.

Otros roles y servicios de la granja de servidores

Nuestro ejemplo no incluye todos los roles, servicios y aplicaciones de servicios que se pueden ejecutar en una granja de servidores SharePoint concreta. No se puede usar un enfoque genérico de alta disponibilidad para todo en una granja de servidores de SharePoint. A continuación se enumeran algunas exclusiones importantes a la hora de usar un enfoque estándar de alta disponibilidad:

Después de diseñar una arquitectura que soporta roles y cargas de trabajo de alta disponibilidad, se pueden usar componentes de tolerancia a errores para incrementar la disponibilidad. Las soluciones de tolerancia a errores están disponibles en la infraestructura, que incluye las bases de datos.

La tolerancia a errores es altamente disponible para casi cualquier componente de hardware de la infraestructura de una granja de servidores SharePoint. Como parte del diseño de alta disponibilidad, se deben determinar las partes de la infraestructura que debe tener tolerancia a errores desde un punto de vista operativo y de costes. Aunque se pueden hacer cada parte tolerante a errores, no significa que tenga que hacerse.

Puesto que la plataforma SharePoint y las cargas de trabajo de su aplicación dependen de la disponibilidad y confiabilidad de todas las bases de datos SharePoint, las bases de datos de alta disponibilidad son un aspecto extremadamente importante de la estrategia de alta disponibilidad. Se puede usar las siguientes características como soluciones de tolerancia a errores para servidores de bases de datos y bases de datos UNRESOLVED_TOKEN_VAL(SharePointAll_2nd_NoVer):

  • Clúster de conmutación por error de SQL Server (instancias de clúster de conmutación (FCI) AlwaysOn en SQL Server 2012)

  • Reflejo de base de datos SQL Server de alta disponibilidad

  • Grupos de disponibilidad AlwaysOn

ImportanteImportante:
SQL Server 2012 AlwaysOn están disponible solo en SQL Server Enterprise.

Acerca de las instancias de clúster de conmutación por error AlwaysOn y de grupos de disponibilidad AlwaysOn

Un clúster de conmutación por error requiere un almacenamiento en disco compartido entre dos equipos. En una configuración de dos nodos, los equipos se configuran como activos/pasivos, lo que proporcionar un instante totalmente redundante del nodo principal. El nodo pasivo solo pasa a estar en línea si falla el nodo principal. El disco compartido solo se presenta en un equipo a la vez. Esta configuración normalmente requiere la mayor cantidad de hardware adicional. En SQL Server 2012, este tipo de configuración de clúster es una instancia de clúster de conmutación por error AlwaysOn y es una forma específica de instalar SQL Server. Debido a los requisitos de configuración, no se puede tomar una instalación estándar de SQL Server y cambiarla fácilmente a una instancia de clúster de conmutación por error.

Un grupo de disponibilidad AlwaysOn es una tecnología diferente en SQL Server 2012 (podría considerarse un descendiente del reflejo de bases de datos) que usa algunas características expuestas por los clústeres de Windows. Sin embargo, no requiero almacenamiento compartido en disco compartido y los equipos de un grupo de disponibilidad no necesitan tener una configuración especializada de SQL Server instalada. Después de agregar un servidor de bases de datos en un clúster de Windows, es bastante fácil habilitar grupos de disponibilidad AlwaysOn y, después, configurar el grupo de disponibilidad que se desee.

En resumen, cualquier servidor que ejecute SQL Server 2012 Enterprise Edition puede usar grupos de disponibilidad AlwaysOn uniéndose a un clúster y configurando el grupo de disponibilidad. Los clústeres de conmutación por error AlwaysOn requieren hardware y pasos de configuración especiales para configurar las instancias de clúster de conmutación por error. Cada una de estas tecnologías se usa para entornos específicos y ambas son competidores complementarios. Para más información sobre estas características, consulte la guía de soluciones AlwaysOn de Microsoft SQL Server para alta disponibilidad y recuperación ante desastres.

ImportanteImportante:
Puesto que cada opción de alta disponibilidad de SQL Server tiene sus propias características, ventajas y desventajas, un opción no es necesariamente mejor que la otra. Por ejemplo, en el caso de un escenario que usa grupo de disponibilidad AlwaysOn, puede ser mejor minimizar la pérdida de datos que ganar el rendimiento que logran las instancias de clústeres de conmutación por error AlwaysOn. Se debe elegir una solución de alta disponibilidad en función de las necesidades empresariales y de los requisitos de la infraestructura de TI.

Un factor determinante a la hora de seleccionar una opción de SQL Server para usar son las bases de datos de datos SharePoint. Es necesario comprender las características de las bases de datos SharePoint 2013. Cada base de datos puede tener restricciones o requisitos específicos que determinarán la solución SQL Server de tolerancia a errores más apropiada y totalmente compatible con el entorno de producción. Se recomienda revisar los artículos siguientes:

Los clústeres de conmutación por error admiten la disponibilidad para una instancia de SQL Server en SQL Server 2008 R2 con Service Pack 1 (SP1) o SQL Server 2012.

NotaNota:
SQL Server Los clústeres de conmutación por error se denominan instancias de clúster de conmutación por error (FCI) AlwaysOn en SQL Server 2012. Para simplificar, el término clúster de conmutación por error se aplica tanto a los clústeres de conmutación por error de SQL Server en SQL Server 2008 R2 con Service Pack 1 (SP1), como al FCI AlwaysOn en SQL Server 2012.

Un clúster de conmutación por error es una combinación de uno o más nodos o servidores y dos o más discos compartidos. Aunque una instancia de un clúster de conmutación por error aparece como un equipo único, la instancia proporciona la conmutación por error de un nodo a otro si el nodo actual deja de estar disponible. SharePoint 2013 se puede ejecutar en cualquier combinación de nodos activos y pasivos en un clúster compatible con SQL Server.

SharePoint 2013 hace referencia al clúster en su conjunto. Por lo tanto, la conmutación por error es automática e imperceptible desde el punto de vista de SharePoint 2013.

NotaNota:
Cuando se produce una conmutación por error planeada o no planeada, se interrumpen las conexiones y deben establecerse de nuevo al pasar de un nodo de clúster a otro.

Para más información sobre los clústeres de conmutación por error de SQL Server, consulte los artículos siguientes:

La ventaja principal de los grupos de disponibilidad AlwaysOn de SQL Server y del reflejo de bases de datos SQL Server es que ambos proporcionan una redundancia de datos completa o casi completa según cómo se configuren para el procesamiento de transacciones. Además de minimizar la pérdida de datos, la conmutación por error automática minimiza el tiempo de inactividad de las bases de datos de producción.

ImportanteImportante:
Aunque SQL Server 2012 admite el reflejo de bases de datos, esta característica ya no se usa. Se recomienda evitar el uso de esta característica en nuevos trabajos de desarrollo. Planee cambiar las aplicaciones que usan esta característica actualmente y use los grupos de disponibilidad AlwaysOn en su lugar.

Grupos de disponibilidad AlwaysOn

La característica de grupos de disponibilidad AlwaysOn de SQL Server es una solución de alta disponibilidad y de recuperación ante desastres que proporciona una alternativa de nivel empresarial al reflejo de bases de datos. Los grupos de disponibilidad AlwaysOn admiten un entorno de conmutación por error para una o varias bases de datos del usuario incluidas en una colección definida por el usuario. Esta colección, un grupo de disponibilidad, está formada por los componentes siguientes:

  • Replicas, que son un conjunto discreto de bases de datos del usuario denominadas bases de datos de disponibilidad que se tratan como una sola unidad. Un grupo de disponibilidad admite una réplica principal y hasta cuatro réplicas secundarias.

  • Una instancia específica de SQL Server para hospedar cada réplica y mantener una copia local de cada base de datos que pertenece al grupo de disponibilidad.

Cuando un grupo de disponibilidad se conmuta por error en una instancia o un servidor de destino, todas las bases de datos del grupo también se conmutan por error. Puesto que SQL Server 2012 puede hospedar varios grupos de disponibilidad en un único servidor, se puede configurar AlwaysOn para que conmute por error en las instancias SQL Server en distintos servidores. Esto reduce la necesidad de servidores de alto rendimiento inactivos en espera para tratar la carga total del servidor principal, lo cual es una de las muchas ventajas de los grupos de disponibilidad.

NotaNota:
Las incidencias de las bases de datos, como una base de datos que se convierte en sospechosa a causa de la pérdida de un archivo de datos, la eliminación de una base de datos o la corrupción de un registro de transacción, no causan una conmutación por error.

Para obtener más información sobre las ventajas de los grupos de disponibilidad AlwaysOn, así como una introducción a la terminología de los grupos de disponibilidad AlwaysOn, consulte Grupos de disponibilidad AlwaysOn (SQL Server).

Creación de reflejos de base de datos

La creación de reflejos de base de datos proporciona redundancia de base de datos al conservar una copia reflejada de las bases de datos en el servidor de bases de datos principal. La creación de reflejos se implementa por base de datos y solo funciona con bases de datos que usan el modelo de recuperación completa.

NotaNota:
Existen dos modos de funcionamiento de la creación de reflejos. Uno de ellos, el modo de seguridad alta, admite la operación sincrónica. En el modo de seguridad alta, cuando se inicia una sesión, el servidor reflejado sincroniza la base de datos reflejada y la base de datos principal lo más rápido posible. Una vez sincronizadas las bases de datos, se escribe una transacción en el registro del servidor secundario y se vuelve a reproducir. (El control vuelve al servidor principal una vez protegida la transacción.) El otro modo de creación de reflejos es de rendimiento alto y utiliza la operación asincrónica para reducir la latencia de la transacción, con el coste de una mayor pérdida de datos.

Para la creación de reflejos de alta disponibilidad en una granja de servidores SharePoint, se debe usar el modo de seguridad alta con conmutación por error automática. La creación de reflejos de seguridad alta requiere tres instancias de servidor: una principal, un reflejo y un testigo. El servidor testigo habilita SQL Server para que conmute por error automáticamente del servidor principal al servidor reflejado. La conmutación por error a la base de datos reflejada tarda normalmente unos segundos.

Para obtener información general sobre la creación de reflejos de bases de datos, consulte Creación de reflejo de la base de datos.

ImportanteImportante:
No se pueden crear reflejos de las bases de datos configuradas para usar el proveedor de almacén BLOB remoto FILESTREAM de SQL Server.

La elección de una tecnología SQL Server para la alta disponibilidad y la recuperación ante desastres debería basarse en los objetivos de negocio de la organización para el Objetivo de punto de recuperación (RPO) y el Objetivo de tiempo de recuperación (RTO). Aunque RPO y RTO se asocian normalmente con la recuperación ante desastres, algunos eventos de error se encuentran fuera del ámbito de un desastre pero requieren recuperación desde un medio de copia de seguridad local en la base de datos principal.

ImportanteImportante:
En función de la base de datos específica, las distintas bases de datos de SharePoint 2013 solo admiten opciones específica de alta disponibilidad de SQL Server. Para más información, consulte Compatibilidad de alta disponibilidad y opciones de recuperación ante desastres para bases de datos de SharePoint (SharePoint 2013).

En la tabla siguiente se proporciona una comparación general de los resultados RPO y RTO que las soluciones SQL Server disponibles logran.

NotaNota:
Los tiempos en la tabla siguiente son para comparar las opciones de bases de datos. En la práctica, todos los tiempos dependen de la carga de trabajo, el volumen de datos y los procedimientos de conmutación por error.

Comparación de RPO y RTO en función de la tecnología de bases de datos

Solución SQL Server Pérdida de datos potencial (RPO) Tiempo de recuperación potencial (RTO). Conmutación por error automática Secundarias legibles
ImportanteImportante:
SharePoint 2013 no admite esta configuración.

Grupo de disponibilidad AlwaysOn (confirmación sincrónica)

Cero

Segundos

0 - 2

Grupo de disponibilidad AlwaysOn (confirmación asincrónica)

Segundos

Minutos

No

0 - 4

Instancia de clúster de conmutación por error AlwaysOn

No se aplica

Una instancia de clúster de conmutación por error por sí sola no proporciona protección de datos. La cantidad de pérdida de datos depende de la implementación del sistema de almacenamiento.

Segundos a minutos

No se aplica

Creación de reflejos de base de datos: seguridad alta (modo sincrónico + servidor testigo)

Cero

Segundos

No se aplica

Creación de reflejos de base de datos: rendimiento alto (modo asincrónico)

Segundos

Minutos

No

No se aplica

Copia de seguridad, copia, restauración.

Horas o cero si se puede obtener acceso al final del registro después del error.

Horas a días

No

No durante una restauración

Comparación del clúster SQL Server, el grupo de disponibilidad AlwaysOn y el reflejo de base de datos

Clúster de conmutación por error de SQL Server Grupos de disponibilidad AlwaysOn de SQL Server 2012 Reflejo de alta disponibilidad de SQL Server

Tiempo de la conmutación por error

El miembro del clúster toma el control casi inmediatamente después del error. Se produce un retardo mientras el nodo del clúster se pone en funcionamiento.

La réplica toma el control casi inmediatamente después del error. Se produce un retardo mientras la réplica secundaria se pone en funcionamiento.

El reflejo toma el control tan pronto como se procesa la cola rehecha.

Coherencia de las transacciones

Simultaneidad de las transacciones

Tiempo de recuperación

Menos tiempo de recuperación que un grupo de disponibilidad.

Mayor tiempo de recuperación que un clúster de conmutación por error, pero más rápido que una solución reflejada.

Tiempo de recuperación ligeramente mayor que un clúster o un grupo de disponibilidad.

Pasos necesarios para la conmutación por error

Los nodos de la base de datos detectan un error automáticamente.

SharePoint 2013 hace referencia al clúster para que la conmutación por error sea directa y automática.

La escucha del grupo de disponibilidad detecta un error automáticamente y la conmutación por error es directa y automática.

La base de datos detecta un error automáticamente.

SharePoint 2013 tiene constancia de la ubicación del reflejo si este se configuró correctamente para que la conmutación por error sea automática.

Protección frente a errores de almacenamiento

El clúster de conmutación por error por sí solo no proporciona protección de datos. La cantidad de pérdida de datos depende de la implementación del sistema de almacenamiento. Por ejemplo, un entorno SAN tiene componentes redundantes como múltiples rutas de archivo, RAID y reservas activas.

Protege frente a errores de almacenamiento ya que la réplica principal escribe en los discos locales de las réplicas secundarias.

Protege frente a errores de almacenamiento ya que tanto el servidor principal como el de la base de datos reflejada escriben en discos locales.

Tipos de almacenamiento admitidos

Requiere almacenamiento compartido, que es más caro que el almacenamiento dedicado.

Puede usar soluciones de almacenamiento conectadas directamente más económicas.

Puede usar almacenamiento conectado directamente más económico.

Requisitos de ubicación

Los miembros del clúster deben encontrarse en la misma subred.

NotaNota:
Este no es el caso con SQL Server 2012.

Las réplicas pueden encontrarse en diferentes subredes si la latencia no causa problemas de rendimiento.

Los servidores principal, reflejado y testigo deben estar en la misma LAN (ida y vuelta con una latencia de hasta 1 milisegundo).

Modelo de recuperación

Se recomienda el modelo de recuperación completa de SQL Server. Se puede usar el modelo de recuperación simple de SQL Server. Sin embargo, el único punto de recuperación disponible si se pierde el clúster será la última copia de seguridad completa.

Requiere el modelo de recuperación completa de SQL Server 2012.

Requiere el modelo de recuperación completa de SQL Server.

Sobrecarga de rendimiento

Durante una conmutación por error se puede producir alguna disminución del rendimiento. El servidor no estará disponible durante la conmutación por error y las conexiones se interrumpen y se vuelven a establecer en el nuevo nodo activo.

Los grupos de disponibilidad AlwaysOn introducen la latencia transaccional, debido a la confirmación sincrónica en las réplicas secundarias. La cantidad de latencia depende del número de réplicas secundarias que se deben sincronizar.

La sobrecarga de la memoria y del procesador es mayor que en los clústeres, pero menor que en la creación de reflejos.

La creación de reflejos de alta disponibilidad introduce la latencia transaccional, ya que es sincrónica. También requiere una sobrecarga de la memoria y del procesador adicional.

Sobrecarga de operaciones

Se configuran y mantienen en el nivel del servidor.

La sobrecarga operativa es mayor que en los clústeres y la creación de reflejos. AlwaysOn requiere sobrecarga a nivel del servidor de base de datos SQL Server, además de a nivel de Windows Server.

NotaNota:
Los objetos de nivel de servidor como, por ejemplo, los trabajos de agente y los inicios de sesión deben mantenerse manualmente.

Si se agregan bases de datos de contenido, se deben agregar a un grupo de disponibilidad y, después, sincronizar la réplica principal con las réplicas secundarias.

Un entorno de granja de servidores SharePoint requiere varios pasos de configuración para asegurarse de que la cadena de conexión de SharePoint 2013 está asociada correctamente con el nombre de la escucha del grupo de disponibilidad.

La sobrecarga de operaciones es mayor que en los clústeres. Se debe configurar y mantener para todas las bases de datos. La reconfiguración después de la conmutación por error es manual.

NotaNota:
Los objetos de nivel de servidor como, por ejemplo, los trabajos de agente y los inicios de sesión deben mantenerse manualmente.

Si se agregan bases de datos de contenido, se deben agregar al principal y después sincronizarlas con el principal del reflejo.

Algunas empresas tienen centros de datos ubicados cerca los unos de los otros, conectados mediante cables de fibra óptica de banda ancha. Si este entorno está disponible, es posible configurar ambos centros de datos como una sola granja de servidores. Esta topología de granja de servidores distribuida se denomina granja de servidores "expandida".

Para que una arquitectura de granja de servidores expandida funcione como solución de alta disponibilidad compatible, se deben cumplir los siguientes requisitos previos:

  • Hay una latencia dentro de la granja de servidores de gran constancia, de <1ms (unidireccional), el 99,9% del tiempo durante un período de diez minutos. (La latencia dentro de la granja se define comúnmente como la latencia entre los servidores web front end y los servidores de bases de datos.)

  • La velocidad de ancho de banda debe ser de al menos 1 gigabit por segundo.

Para proporcionar tolerancia a errores en una granja de servidores expandida, usa las instrucciones de prácticas recomendadas estándar para configurar aplicaciones de servicio y bases de datos redundantes.

En la ilustración siguiente se muestra una granja de servidores expandida.

Granja de servidores expandida

Topología de una granja expandida que utiliza dos centros de datos para ofrecer una disponibilidad elevada.

La estrategia de alta disponibilidad debe incluir las operaciones de copia de seguridad y de restauración apropiadas para asegurar que la granja de servidores es resistente. En el caso de un incidente, como un error del medio o del usuario, se debe poder restaurar la parte afectada del entorno o de los datos de la granja de servidores de forma inmediata. Una solución de copia de seguridad y de restauración efectiva debe permitir el cumplimiento de los objetivos de tiempo de recuperación (RTO) y los objetivos de recuperación potencial (RPO) definidos.

Para más información, consulte Copia de seguridad y restauración de SharePoint 2013.

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft