Requisitos y consideraciones para la implementación de Analysis Services

El rendimiento y la disponibilidad de una solución dependen de muchos factores, incluidas las funcionalidades del hardware subyacente, la topología de la implementación del servidor, las características de la solución (por ejemplo, tener particiones distribuidas entre varios servidores o usar el almacenamiento ROLAP que requiere acceso directo al motor relacional), contratos de nivel de servicio y la complejidad del modelo de datos.

Requisitos de memoria y procesador

Analysis Services necesita más recursos de memoria y procesador en los casos siguientes:

• Al procesar cubos grandes o complejos. Estos requieren más recursos de memoria y procesador que los cubos pequeños o simples.

• Cuando aumenta el número de cubos dentro de una base de datos única.

• Cuando aumenta el número de bases de datos dentro de una sola instancia de Analysis Services.

• Cuando aumenta el número de instancias de Analysis Services en un solo equipo.

• Cuando aumenta simultáneamente el número de usuarios que acceden a los recursos de Analysis Services.

La cantidad de recursos de memoria y procesador disponibles para Analysis Services varía en función de la edición de SQL Server, el sistema operativo, la funcionalidad de hardware y si usa procesadores virtuales o físicos. Para obtener más información, siga estos vínculos:

Requisitos de hardware y software para instalar SQL Server 2014

Límites de capacidad de proceso por edición de SQL Server

Características compatibles con las ediciones de SQL Server 2014

Especificaciones de capacidad máxima (Analysis Services)

Requisitos de espacio en disco

Los distintos aspectos de la instalación de Analysis Services y las tareas relacionadas con el procesamiento de objetos requieren diferentes cantidades de espacio en disco. En la lista siguiente se describen estos requisitos.

Cubos
Los cubos que tienen tablas de hechos grandes requieren más espacio en disco que los cubos que tienen tablas de hechos pequeñas. De forma similar, aunque en menor medida, los cubos que tienen muchas dimensiones grandes requieren más espacio en disco que los cubos que tienen menos miembros de dimensión. Por lo general, puede esperar que una base de datos de Analysis Services requiera aproximadamente el 20 % del espacio necesario para los mismos datos almacenados en la base de datos relacional subyacente.

Agrupaciones
Las agregaciones requieren espacio adicional proporcional a las agregaciones, cuantos más agregaciones haya, más espacio es necesario. Si evita crear agregaciones innecesarias, el espacio en disco adicional necesario para las agregaciones normalmente no debe superar aproximadamente el 10 % del tamaño de los datos almacenados en la base de datos relacional subyacente.

Minería de datos
De forma predeterminada, las estructuras de minería de datos almacenan en caché el disco del conjunto de datos con el que se entrenan. Para quitar estos datos almacenados en caché del disco, puede usar la opción Procesar borrar estructura de procesamiento en el objeto de estructura de minería de datos. Para obtener más información, vea Requisitos y consideraciones de procesamiento (minería de datos).

Procesamiento de objetos
Durante el procesamiento, Analysis Services almacena copias de los objetos que está procesando en la transacción de procesamiento en el disco hasta que finalice el procesamiento. Cuando finaliza el procesamiento, las copias procesadas de los objetos reemplazan a los objetos originales. Por lo tanto, debe proporcionar suficiente espacio en disco adicional para que se procese una segunda copia de cada objeto. Por ejemplo, si planea procesar un cubo completo en una sola transacción, necesita suficiente espacio en disco duro para almacenar una segunda copia del cubo completo.

Consideraciones sobre disponibilidad

En un entorno de Analysis Services, un cubo o modelo de minería de datos puede no estar disponible para realizar consultas debido a un error de hardware o software. Un cubo también puede no estar disponible porque debe procesarse.

Proporcionar disponibilidad en caso de errores de hardware o software

El hardware o el software pueden producir errores por diversos motivos. Sin embargo, mantener la disponibilidad de la instalación de Analysis Services no solo consiste en solucionar el origen de esos errores, sino también en proporcionar recursos alternativos que permitan al usuario seguir usando el sistema si se produce un error. Los servidores de agrupación en clústeres y de equilibrio de carga se usan normalmente para proporcionar los recursos alternativos necesarios para mantener la disponibilidad cuando se producen errores de hardware o software.

Para proporcionar disponibilidad en caso de error de hardware o software, considere la posibilidad de implementar Analysis Services en un clúster de conmutación por error. En un clúster de conmutación por error, si se produce un error en el nodo principal por cualquier motivo o si se debe reiniciar, la agrupación en clústeres de Microsoft Windows hace la conmutación a un nodo secundario. Después de la conmutación por error, que se produce muy rápidamente, cuando los usuarios ejecutan consultas, acceden a la instancia de Analysis Services que se ejecuta en el nodo secundario. Para obtener más información sobre los clústeres de conmutación por error, consulte Tecnologías de Windows Server: Clústeres de conmutación por error.

Otra solución para problemas de disponibilidad es implementar el proyecto de Analysis Services en dos o más servidores de producción. A continuación, puede usar la característica Equilibrio de carga de red (NLB) de los servidores de Windows para combinar los servidores de producción en un único clúster. En un clúster NLB, si un servidor del clúster no está disponible debido a problemas de hardware o software, el servicio NLB dirige las consultas de usuario a los servidores que todavía están disponibles.

Proporcionar disponibilidad durante el procesamiento de cambios estructurales

Algunos cambios en un cubo pueden hacer que el cubo no esté disponible hasta que se procese. Por ejemplo, si realiza cambios estructurales en una dimensión de un cubo, aunque vuelva a procesar la dimensión, cada cubo que use la dimensión modificada también debe procesarse. Hasta que procese esos cubos, los usuarios no pueden consultarlos ni consultar los modelos de minería de datos basados en un cubo que tenga la dimensión modificada.

Para proporcionar disponibilidad mientras procesa cambios estructurales que pueden afectar a uno o varios cubos en un proyecto de Analysis Services, considere la posibilidad de incorporar un servidor provisional y usar el Asistente para sincronizar bases de datos. Esta característica le permite actualizar datos y metadatos en un servidor de almacenamiento provisional y, a continuación, realizar una sincronización en línea del servidor de producción y el servidor de ensayo. Para obtener más información, vea Synchronize Analysis Services Databases.

Para procesar de forma transparente las actualizaciones incrementales de los datos de origen, habilite el almacenamiento en caché proactivo. El almacenamiento en caché proactivo actualiza cubos con nuevos datos de origen sin necesidad de procesamiento manual y sin afectar a la disponibilidad de cubos. Para obtener más información, consulte Caché proactiva (Particiones).

Consideraciones sobre escalabilidad

Varias instancias de Microsoft SQL Server y Analysis Services en el mismo equipo pueden causar problemas de rendimiento. Para resolver estos problemas, una opción puede ser aumentar los recursos de procesador, memoria y disco en el servidor. Sin embargo, es posible que también tenga que escalar las instancias de SQL Server y Analysis Services en varios equipos.

Dimensionamiento de Servicios de Análisis en varios equipos

Hay varias maneras de escalar una instalación de Analysis Services en varios equipos. Estas opciones se describen en la lista siguiente.

• Si hay varias instancias de Analysis Services en un único equipo, puede mover una o varias instancias a otro equipo.

• Si hay varias bases de datos de Analysis Services en un único equipo, puede mover una o varias de las bases de datos a su propia instancia de Analysis Services en un equipo independiente.

• Si una o varias bases de datos relacionales proporcionan datos a una base de datos de Analysis Services, puede mover estas bases de datos a un equipo independiente. Antes de mover las bases de datos, tenga en cuenta la velocidad de red y el ancho de banda que existen entre la base de datos de Analysis Services y sus bases de datos subyacentes. Si la red es lenta o congeste, mover las bases de datos subyacentes a un equipo independiente reducirá el rendimiento del procesamiento.

• Si el procesamiento afecta al rendimiento de las consultas, pero no puede procesar durante tiempos de carga reducida de consultas, considere la posibilidad de mover las tareas de procesamiento a un servidor de almacenamiento provisional y, a continuación, realizar una sincronización en línea del servidor de producción y el servidor de ensayo. Para obtener más información, vea Synchronize Analysis Services Databases. También puede distribuir el procesamiento entre varias instancias de Analysis Services mediante particiones remotas. El procesamiento de particiones remotas usa los recursos de procesador y memoria en el servidor remoto, en lugar de los recursos del equipo local. Para obtener información sobre la administración de particiones remotas, consulte Creación y administración de una partición remota (Analysis Services).

• Si el rendimiento de las consultas es deficiente, pero no puede aumentar los recursos de procesador y memoria en el servidor local, considere la posibilidad de implementar un proyecto de Analysis Services en dos o más servidores de producción. A continuación, puede usar el equilibrio de carga de red (NLB) para combinar los servidores en un único clúster. En un clúster NLB, las consultas se distribuyen automáticamente en todos los servidores del clúster NLB.