Pregunta:
- Clúster de instancias múltiples de SQL Server 2008 R2 (en VMware vSphere 5.1)
- 2 nodos, cada uno con 2 instancias (4 instancias en total)
- 16 GB de RAM por nodo.
La única vez que las instancias están en el mismo nodo es cuando parcheo el otro nodo.
La recomendación de "memoria máxima del servidor" de Brent Ozar es dejar Windows 4GB o 10%, lo que sea mayor.
Dado que este es un clúster, ¿cómo debo configurar la memoria máxima en cada nodo? ¿Debería tratar a cada uno como un servidor independiente? Esto aseguraría que la memoria en cada nodo no se desperdicie. Sin embargo, en una falla de nodo, el total máximo de memoria para las 4 instancias excedería la memoria del sistema de un solo nodo. ¿Causará esto algún problema en el período de tiempo hasta que recuperemos el segundo nodo? ¿Necesito reducir la configuración de memoria máxima en las 4 instancias hasta que se recupere el nodo secundario? ¿O SQL Server es lo suficientemente inteligente como para seguir funcionando (usando el archivo de paginación si es necesario)?
Respuesta:
Debe aprovechar al máximo el hardware cuando esté en una configuración óptima y ajustar cuando esté en modo de mantenimiento. Y sí, tendrá un problema mientras ambas (¿o las cuatro?) Instancias estén activas en el mismo nodo. Dado que una conmutación por error induce el inicio de un servicio en el nodo ahora activo, puede ajustar la memoria máxima de cada servidor en ese evento mediante un procedimiento de inicio. Escribí sobre esto aquí, pero por una razón diferente (fallando a un nodo con una cantidad diferente de memoria):
Básicamente, solo necesita verificar si ambas instancias están en el mismo nodo (y esto requerirá que se configure un servidor vinculado en ambas direcciones) y ajustar en consecuencia. Un ejemplo muy rápido y completamente no probado basado en la publicación de mi blog y asumiendo que solo hay una instancia en cada nodo a la vez actualmente (la pregunta es un poco ambigua si tiene 2 instancias en total o 4):
CREATE PROCEDURE dbo.OptimizeInstanceMemory
AS
BEGIN
SET NOCOUNT ON;
DECLARE
@thisNode NVARCHAR(255) = CONVERT(NVARCHAR(255),
SERVERPROPERTY('ComputerNamePhysicalNetBIOS'),
@otherNode NVARCHAR(255),
@optimalMemory INT = 12288, -- 12 GB
@sql NVARCHAR(MAX);
SET @sql = N'SELECT @OtherNode = CONVERT(NVARCHAR(255),
SERVERPROPERTY(N''ComputerNamePhysicalNetBIOS''));';
EXEC [SERVER\INSTANCE].master..sp_executesql @sql,
N'@OtherNode NVARCHAR(255) OUTPUT', @OtherNode OUTPUT;
IF @thisNode = @otherNode
BEGIN -- we're on the same node, let's make everyone happy
SET @optimalMemory = 6144;
END
SET @sql = N'EXEC sp_configure N''max server memory'', @om;
RECONFIGURE WITH OVERRIDE;';
EXEC master..sp_executesql @sql, N'@om INT', @optimalMemory;
EXEC [SERVER\INSTANCE].master..sp_executesql @sql, N'@om INT', @optimalMemory;
END
GO
EXEC [master].dbo.sp_procoption
N'dbo.OptimizeInstanceMemory', 'startup', 'true';
Por supuesto, créelo de nuevo en la otra instancia, intercambiando el nombre del servidor vinculado utilizado.
Esto se vuelve un poco más complejo si tiene que ajustar dependiendo de si está compartiendo el nodo actual con 1, 2 o 3 instancias más.
Tenga en cuenta que esto causará otros efectos secundarios, como borrar el caché del plan (en el caso de que una de las instancias no se reinicie o falle, en cuyo caso el caché del plan estaría vacío de todos modos), pero estos son posiblemente mejores que dejando que ambas instancias asuman que todavía tienen 12 GB de memoria para jugar; habrá mucha paliza si ambos se usan mucho.
Es posible que también desee considerar otras opciones, como maxdop global, afinidad NUMA / CPU, etc., según la sensibilidad del sistema a la cantidad de recursos disponibles.