Работа SQL server 2000 в кластере

[Dmitry67]

Интересует реальный опыт (у меня был негативный на 6.5)
А именно оценка отношения вероятности ситуаций

1. Сработало - то есть управление перескочило с одного сервера на другой
2. Сервер умер тихо и ОС не поняла что он умер. Пришлось пихать его вручную (то есть с точки зрения кластера все нормально, а на самом деле SQL server попал в какой то глухой клинч, хотя SQL server сервис работает)
3. Сработало, но вторая инстанция не поднялась или сделала reject базы, потому что первая как то их запортила и/или проблемы с IO
4. Кластер ни при чем, Но пользователи все равно не смогли работать с сервером (сетка, электричество, итд)

То есть вероятность 1 / (вероятность 1+2+3+4 ; все случаи когда пользователь не смог работать с сервером) дает оценку "кпд" кластера, в каком % случаев он реально спас ситуацию

Спасибо

[Dmitry67]

P.S.
Про другие базы (Oracle/DB2) тоже можно...

[zVlad]

Не у кого что ли нет кластеров?
Кстати в случае DB2 на мэйнфрэйм это называется Data Sharing.
У нас это не используется, но есть намерение. Знаю что многие более крупные фирмы чем наша (провинциального уровня кстати) используют это успешно. Оно работает и вопрос вероятности той или иной, из перечисленных Dmitry67, ситуации просто не уместен.
Data Sharing основывается на трёх китах - аппаратные средства (SysPlex), системные (Coupling Facility CF), и собственно режим работы DB2 в так называемой Data Sharing Group. Причем аппаратные и системные средства используются не только DB2 но и другими подсистемами и собственно ОС - интегрированный каталог, система секьюрити, единая система управления заданиями и т.д.
Осмелюсь предположить, что Oracle RAC опирается только на самого себя не имея ни системной ни аппартной поддержки в построении своего кластера. А как с этим в случае MS SQL?

[verzlo]

Интересует реальный опыт (у меня был негативный на 6.5)
А именно оценка отношения вероятности ситуаций

1. Сработало - то есть управление перескочило с одного сервера на другой
2. Сервер умер тихо и ОС не поняла что он умер. Пришлось пихать его вручную (то есть с точки зрения кластера все нормально, а на самом деле SQL server попал в какой то глухой клинч, хотя SQL server сервис работает)
3. Сработало, но вторая инстанция не поднялась или сделала reject базы, потому что первая как то их запортила и/или проблемы с IO
4. Кластер ни при чем, Но пользователи все равно не смогли работать с сервером (сетка, электричество, итд)

То есть вероятность 1 / (вероятность 1+2+3+4 ; все случаи когда пользователь не смог работать с сервером) дает оценку "кпд" кластера, в каком % случаев он реально спас ситуацию

Спасибо

Выскажу ИМХО на основе опята работы с различными кластерами (Failover, Failsafe) на различных платформах (UNIX - AIX, SUN, HP / Windows) и различныз БД - Оракл и SQL Server.
Вопрос несколько некорректен на мой взгляд: при современных clusterware and clusteraware databases и нормальной настройке кластеров вариантов 2 и 3 не должно быть в принципе. Вариант 4 от кластера не зависит никак по определению (опять же существуют redundent рещения и для Network и для power supplies).
Все зависит от конкретного аппликейшн ( 24/7 availability, transportability, load balance etc), и в зависимости от требований выбирается оптимальное решение в соответствии с выделенным бюджетом...
Оценивать КПД кластера тоже не считаю корректным, это как страховка на машину или дом, вы платите каждыц месяц и если с вами или машиной ничего не случилось, то вы ее бенефитами не воспользуетесь никогда. Но и понятно, но если вдруг вы разобьете машину или на нее упадет дерево/град, то все засходы покроются...
Как и в страховке, вы пытаетесь оптимально минимизировать затраты между стоимостью кластера в соотношении с обычной системой и риском потери. простоя и т.д.
У нас Clusters - это в основном решение для обеспечения 24/7 для missin critical application/databases, т.е. от которых зависят финансы и sales компании. Для disaster recovery мы обычно используем backups tored off-site или stand-by databases in different regional datacenters.

Мы делали очень много тестов на кластерах и у нас все работает. Что касается SQL Server, то я работал с класерами начиная с 7.0 версии и не знаю как они вели себя в 6.5. Про 7.0 ничего плохого сказать не могу - свою работу он делает нормально ( у нас в основном исспользуют его как ACTIVE PASSIVE).
По поводу Оракла - у него более широкий выбор и вы можете использовать как сами кластерные решения на уровне OS (как Veritas Cluster Server), Sun Cluster, HP MC Servie Guard etc., так и Оракловкские RAC и FailSafe.

[Kon]

У меня сейчас 2 кластера, один Active/Passive, второй Active/Active (multiple instances-много возни). С SQL 7 возникало довольно много проблем, но ето было до SP3, может сейчас лучше. Сейчас работает на 2000. Также были проблемы с DELL hardware, особенно их SAN. Сейчас использую Compaq и EMC SAN.

По вопросам:

1) Срабатывает 99% случаев.
2) Да случалось. Когда SQL crashes и генерирует дaмп a SQL сервиc продолжает работать но клиенти не могут соеденится. Требуется failover вручную. Я написал простой ckрипт который соеденяется с сервером через osql и пытается что то select. NT админ поставил ето на scheduler, и в случае если сервер не доступен, он fails over через ckрипт.
3) Случалось на 7.
4) Да, проблемы возможны. Моя основная головная боль ето SAN- single point of failure. Такжe возможны проблемы с сообщением между нодами.
Вообще большинство проблем с кластерами было с ОС и железом. Если НТ clustering хорошо настроенно то проблем с SQL быть не должо.

В зависимости от позволенного downtime нужно решать нужен ли кластер. Иногда рентабельней сделать stand by сервер с log shipping или replication.

[Dmitry67]

Спасибо огромное !!!

[tengiz]

2) Да случалось. Когда SQL crashes и генерирует дaмп a SQL сервиc продолжает работать но клиенти не могут соеденится. Требуется failover вручную. Я написал простой ckрипт который соеденяется с сервером через osql и пытается что то select.

Это странно. В SQL Server 2000 состояние кластерного узла именно так и определяется - специальный системный поток пытается соединиться к серверу и выполнить что-то вроде select @@version. Поэтому в описанной Вами ситуации должен был бы произойти автоматический failover без дополнительного ручного подталкивания.

[hren]

У меня опыт с Oracle на MC Serviceguard на HP-UX, несколько кластеров с разным железом, разным количеством пакетов и разными версиями Oracle и приложений над ним. Все случаи сбоев (реальных и тестовых) отрабатывались корректно, пакеты перекатывались и поднимались. Бывали небольшие проблемы с восстановлением штатной конфигурации после возвращения работоспособности сломанного узла, но во всех случаях эти проблемы были вызваны ошибками в модифицированных скриптах.

[hren]

Осмелюсь предположить, что Oracle RAC опирается только на самого себя не имея ни системной ни аппартной поддержки в построении своего кластера.

Это не совсем верно. Например, в случае HP-UX, одновременно с RAC устанавливается Serviceguard Extension for Real Application Clusters (eRAC), который обеспечивает системную поддержку. С другой стороны, RAC может работать и сам по себе с некоторыми ограничениями.

[zVlad]

Осмелюсь предположить, что Oracle RAC опирается только на самого себя не имея ни системной ни аппартной поддержки в построении своего кластера.

Это не совсем верно. Например, в случае HP-UX, одновременно с RAC устанавливается Serviceguard Extension for Real Application Clusters (eRAC), который обеспечивает системную поддержку. С другой стороны, RAC может работать и сам по себе с некоторыми ограничениями.

Serviceguard Extension - это НР-шный компонент для RAC?

[verzlo]

Осмелюсь предположить, что Oracle RAC опирается только на самого себя не имея ни системной ни аппартной поддержки в построении своего кластера.

Это не совсем верно. Например, в случае HP-UX, одновременно с RAC устанавливается Serviceguard Extension for Real Application Clusters (eRAC), который обеспечивает системную поддержку. С другой стороны, RAC может работать и сам по себе с некоторыми ограничениями.

Serviceguard Extension - это НР-шный компонент для RAC?

Почти.. Точнее это НР ный компонент в дополнение к собственной кластерваре MC Service Guard ,которая ставится для поддержиния физического хардваре кластера и используется для поддержки РАК.
Почти у каждого ОС производителя кластерного ПО есть свои примочки для стандартной кластерной ОС для поддержки Оракловского РАК.
Так например в Веритас это Veritas Cluster Server Advanced Database Edition .
Кстати у Оракла есть своя собственная Кластерваре - в 9i она правда может ставиться только на Винды и Линукс. В 10Г вроде как включена поддержка и для остальных ОС но не известно как она будет работать, поэтому доверия к ней пока большого нет...
Вообще кластера на Юникс и Видноус очень различаются в плане сложности конфигурирования и управления и соответственно надежности...