Experiência com cluster assimétrico (hardware não idêntico) cluster do SQL Server 2005 / Win 2003

Question

Eu sou razoavelmente bom em lidar com clusters do SQL Server; Eu estou querendo saber se as pessoas têm experiência, boa ou ruim, usando uma mistura de diferentes modelos de servidores do mesmo fornecedor em um cluster do SQL 2005.

Suponha que:

1. Eu tenho um mais poderoso, mais RAM, mais shizzle box e um menos poderoso, menos memória, menos shizzle box unidos em um cluster de 2 nós. Estas seriam máquinas HP DL380 e 580 (não que isso deva importar)

2. Eu entendo e automatizo o processo de gerenciamento de memória para cada instância do SQL, portanto não há contenção de memória quando as instâncias do SQL executam failover. Basicamente, estou pensando que um proc CLR irá monitorar as instâncias e autorregular os limites de memória em cada instância, para que eles não paginem ou pise um no outro.

3. Eu vejo o fato de que as instâncias podem ser mais lentas e / ou sob pressão de memória se elas compartilham um nó "menor", e está tudo bem. A empresa pode lidar com uma instância mais lenta em um cenário de problema do servidor.

Razoável? Alguma "pegadinha" para tomar cuidado?

Mais informações 28/10: fazendo algumas experiências com um cluster de teste, descubro que a reconfiguração da memória max / min está OK desde que a instância ainda não esteja sob pressão de memória. Se eu torturar o sistema com uma consulta enorme que exige uma grande quantidade de RAM e simultaneamente ajustar a alocação de memória a um valor menor do que o que está sendo usado ativamente, é possível executar a instância sem memória e interrompê-la. (situação infeliz). Muitas mensagens de falta de memória no registro de erros, falha, queima ... É um caso extremo, mas é bom saber.

Parece, então, que seria realmente seguro configurar isso na inicialização da instância, como em um script de inicialização que diz "Estou no node1, então minhas configurações de RAM são X ou estou no nó dois, então eles são Y ", assim:

link

Atualização: Estou testando uma solução do SQL Agent + PowerShell descrita em mais detalhes aqui .

    

Answer 1

Bem, de acordo com Práticas recomendadas de cluster de servidor ...

Server Error in '/WINDOWSSERVER' Application.
--------------------------------------------------------------------------------
Runtime Error 
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine. 

Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".

<!-- Web.Config Configuration File -->
<configuration>
    <system.web>
        <customErrors mode="Off"/>
    </system.web>
</configuration>

Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.

LOL, mas falando sério ... embora eu sempre tenha usado hardware compatível, não vejo problema algum, desde que o SQL ainda seja responsivo / utilizável no nó mais lento.

    

Answer 2

O único problema é que, para que um cluster do Windows 2003 seja suportado, ele deve ser um da HCL. O Windows 2008 não tem esse problema, pois o único requisito é que ele passe pela validação. No entanto, para o Windows 2003, eles são mais exigentes.

    

Answer 3

Nós fizemos isso com as máquinas que você mencionou. Nós limitamos a memória à quantidade que a máquina menor tinha.

Basically I am thinking a CLR proc will monitor the instances and self-regulate memory caps on each instance, so that they won't page or step on one another.

O que você quis dizer com isso? Eu vi recomendações da microsoft que você não usa quantidades de memória incompatíveis, pois poderia causar grandes problemas no failover. Isso não parece ser algo que você poderia ajustar rapidamente por alguns motivos

1. O nó primário falha ... boom, seu no nó 2, não há tempo para ajustar
2. Reduzir a memória máxima requer uma reinicialização do agente.

Talvez eu esteja entendendo mal ...