Я достаточно хорошо разбираюсь в кластерах SQL Server; Мне интересно, есть ли у людей опыт, хороший или плохой, использования смеси различных моделей серверов от одного и того же поставщика в одном кластере SQL 2005.
Предположим:
У меня есть еще один мощный, больше RAM, больше shizzle box и один менее мощный, меньше памяти, меньше shizzle box, связанные вместе в 2-узловом кластере. Это будут машины HP DL380 и 580 (не то чтобы это имело значение)
Я понимаю И автоматизирую процесс управления памятью для каждого экземпляра SQL, поэтому при отказе экземпляров SQL не возникает конкуренции за память. В основном я думаю, что процесс CLR будет отслеживать экземпляры и саморегулировать ограничения памяти на каждом экземпляре, чтобы они не публиковали страницы и не наступали друг на друга.
Я понимаю, что экземпляры могут быть медленнее и / или испытывать нехватку памяти, если они совместно используют «меньший» узел, и это нормально. Бизнес может справиться с более медленным экземпляром в сценарии проблемы с сервером.
Разумно? Есть ли какие-то «ловушки», на которые следует обратить внимание?
Дополнительная информация 28 октября: проведя несколько экспериментов с тестовым кластером, я обнаружил, что перенастройка максимальной / минимальной памяти в порядке. ПРЕДОСТАВЛЕНА, что экземпляр еще не находится под давлением памяти. Если я замучу систему огромным запросом, который требует большой кусок ОЗУ, и одновременно отрегулирую выделение памяти на меньшее значение, чем то, что активно используется, можно запустить экземпляр из памяти, и он остановится и перезапустится (несчастная ситуация). Множество уродливых сообщений о нехватке памяти в журнале ошибок, сбоях, прожигании ... Это крайний случай, но это полезно знать.
Таким образом, кажется, что было бы действительно безопасно установить это только при запуске экземпляра, так как у него есть сценарий запуска, который говорит: «Я нахожусь на узле 1, поэтому мои параметры ОЗУ - X, или я нахожусь на узле два, поэтому они Y "вот так:
http: //sqlblog.com/blogs/aaron_bertrand ...
Обновление: я тестирую решение SQL Agent + PowerShell, описанное более подробно. Вот.
Ну согласно Лучшие практики кластера серверов...
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, но серьезно ... хотя я всегда использовал подходящее оборудование, я не вижу никаких проблем, пока SQL все еще реагирует / может использоваться на более медленном узле.
Единственная проблема будет заключаться в том, что для поддержки кластера Windows 2003 должен быть один HCL. Windows 2008 не имеет этой проблемы, поскольку единственное требование - это пройти проверку. Однако для Windows 2003 они более разборчивы.
Мы сделали это с машинами, о которых вы упомянули. Мы просто ограничили память до того количества, которое было у меньшей машины.
В основном я думаю, что процесс CLR будет отслеживать экземпляры и саморегулировать ограничения памяти для каждого экземпляра, чтобы они не публиковались и не наступали друг на друга.
Что вы имели в виду? Я видел рекомендации от Microsoft не использовать несовпадающие объемы памяти, так как это может вызвать серьезные проблемы при переключении на другой ресурс. Кажется, это не то, что вы могли бы настроить на лету по нескольким причинам.
Может я недопонимаю ...