SQL Server еквівалентний функціональності Oracle RAC? [зачинено]

Я зробив якийсь гуглінг і не зміг знайти відповідь на це питання останнім часом, ніж кілька років тому, тому я подумав, що запитаю. Функція RAC Oracle пропонує збалансування завантаження як для транзакцій з читанням, так і для запису, а також масштабування та доступність без простоїв (принаймні, наскільки я розумію - ми збираємося розгорнути наші перші бази даних, які використовують RAC, тому ми побачу, як це йде).

Чи є набір функцій SQL Server (або сторонній компонент, який ви можете встановити зверху), який забезпечує еквівалентну функціональність? Ми завжди використовували кластеризацію Windows, де подія відмови викликає близько 20-30 секунд простою SQL - завжди терпимо, але не ідеально. Тепер, коли AlwaysOn у SQL 2012, SQL Server скорочує це приблизно на 15 секунд і додає концепцію баз даних лише для читання, але вони все ще вимагають, щоб транзакції запису заглушувались через одну точку з'єднання (значно вдосконалено, оскільки багато транзакцій є просто читайте, але все ще не дуже завантажуйте балансування), а у випадку відмови вузла або необхідності виправлення, ще простої.

Я вважаю, що це просто більше цікавості - я відчуваю, що це єдина область, за якою SQL Server відстає від Oracle (принаймні серед функцій, які я особисто бачив). Я хотів побачити, чи є якісь варіанти, щоб закрити цей проміжок і, можливо, покращити власне розгортання сервера SQL Server, поки ми будемо чекати, коли буде додана еквівалентна функція Microsoft - можливо, у SQL 2014/2015?

Ні, нічого в SQL Server не може дати вам те саме, що не вийшло .

Наразі єдиною технологією SQL Server, яка дозволяє одночасно записувати на кілька вузлів, є реплікація Peer-to-Peer . Зауважте, що я не сказав "написати масштаб", тому що він працює таким чином, що вся система має здатність запису лише одного вузла. Вступний абзац цієї сторінки формулюється обережно, щоб включати термін "масштабування", не кажучи "написати масштаб". Так, для маркетингу говорять.

З того, що я прочитав , Oracle RAC є тим самим у цьому відношенні. Функціонально, єдине, чого не вистачає у SQL Server у цій конфігурації, - це рішення щодо балансування навантаження, яке є як перевагою (ви можете реалізувати це будь-яким способом), так і недоліком (він не знаходиться у вікні чи не підтримується Microsoft), коли порівняння з конкуруючими продуктами.

І навпаки, Oracle RAC не дає вам того самого, що і SQL Server, поза полем . Наприклад, RAC рекомендується застосовувати з вузлами на відстані 100 км один від одного через затримку в режимі реального часу в мережі, тоді як реплікація однорангової реплікації не має такого обмеження. (Я не кажу, що одне рішення краще, ніж інше: я просто вказую, що вони різні. Бізнес повинен вибрати рішення, яке найкраще відповідає їх конкретним потребам.)

Я DBA, що підтримує як SQL 2000-2012, Oracle 11g, так і OAC 11g RAC.

IMO, Always On Availability Groups у SQL 2012 дуже близький до доступності та масштабованості RAC за значно менших витрат як у доларах, так і складності. Можна масштабувати показання за допомогою запитів до дзеркал, але ви хочете направити весь DML на основний сервер (дзеркала SQL Server не можна оновити). Якщо основний SQL Server виходить з ладу, перехід на одне із дзеркал майже миттєвий. RAC відчуває аналогічну паузу, якщо вузол виходить з ладу, оскільки невдалі транзакції на невдалому вузлі відкочуються тим, що вижив.

Найбільша перевага (IMHO) SQL 2012 AAAG в порівнянні з RAC полягає в тому, що це архітектура, що розділяється нічим. RAC ділиться сховищем. Якщо це не вдається, весь кластер опустився. Це величезна SPOF в RAC, про яку, здається, всі забувають. Якщо ви хочете захистити себе від цього, вам потрібно створити сервер очікування. Якщо ви хочете, щоб це був RAC, вартість просто ускладнюється ще більше.

Прямий відповідь на ваше запитання - ні, SQL Server не має еквівалентної функціональності. Існують аспекти SQL Server, які дають вам потрібну толерантність до відмов (навіть на відміну від SQL Server 2005 при використанні дзеркального відображення БД та дзеркального додатка), однак у Oracle RAC немає 1: 1.

Кращим порівнянням AlwaysOn була б функція Oracle Data Guard. Активно-пасивне кластеризація. (так, ви можете читати з режиму очікування, але він читається лише, тому все одно активний лише один вузол ")

Oracle RAC - це зовсім інша тварина і активно-активна група. Я не бачив жодних кроків, якщо Microsoft коли-небудь захоче це здійснити.

SQL Server 2012/2014 з AlwaysOn додає багато можливостей, що наближають вас до Oracle RAC - а в деяких випадках покращують його. (Нагадаємо, що з RAC вам потрібно використовувати сервер додатків Oracle, weblogic та JDBC - плюс працювати в єдиному центрі обробки даних, і додаток може підключатися до одного кластеру RAC - спільне зберігання означає, що RAC не працює в хмарі) .

За допомогою програми AlwaysOn ви отримуєте вторинники лише для читання (4 на 12, 8 у 14) та підтримку автоматичного відключення. Хоча деякі речі є складними - AlwaysOn не підтримує балансування навантаження - якщо ви не пишете сценарій, він завжди малюватиме перший сервер у списку. Відмова також впливає на додаток - він не прозорий, тому програми, можливо, доведеться перезапустити.

Повне розкриття інформації - я працюю в компанії, яка виробляє програмне забезпечення, яке розширює AlwaysOn. Наше базування програмного забезпечення для балансування завантаження баз даних SQL Server - воно читає / записує розділене від імені програми, робить балансування завантаження на основі часу реакції, яке охоплює центри обробки даних, і черги вхідних записів / транзакцій під час відмови, щоб додатки не бачили помилок . Подивіться, як Microsoft, Dell, Quicken Loans та інші підприємства використовують програмне забезпечення ScaleArc для розширення SQL Server AlwaysOn та отримання RAC-подібних можливостей без змін додатків.