Реплікація проти Кластеризації: порівняльний погляд один на одного
Ми знаємо, що все (або майже все) комп'ютерні терміни походять від стандартних англійських слів. Такі слова стали буденним, звичним для слуху і багатьма асоціюється виключно тільки з ІТ. Але якщо подивитися на ці слова з точки зору початкового визначення, то це дозволяє глибше зрозуміти чому для того чи іншого терміна було вибрано саме це конкретне англійське слово.
Об'єднання всіх цих значень дозволяє нам добре зрозуміти, що означає реплікація для тих, хто працює в ІТ:
Реплікації - повторення запису даних, таким чином створює точну копію даних, з тим щоб зменшити помилки (і час простою) у міру зростання бази даних.
Кластер - інша справа. Для нього існує вісім визначень в словнику Collins (друге видання). Всі вони містять одну і ту ж основу (яка дає тільки основні вказівки на те, що означає кластеризація в ІТ): об'єднання подібних речей в групи. У Великому Енциклопедичному словнику всі терміни також пов'язані з об'єднанням однотипних об'єктів в групи. Таким чином, кластер в ІТ можна описати так:
КЛАСТЕР - об'єднання декількох однорідних елементів, яке може розглядатися як самостійна одиниця, що володіє певними властивостями
Ми розуміємо англійську етимологію цих термінів в ІТ, але що реплікація і кластеризація означають з точки зору баз даних? Які відносні переваги і недоліки кожного підходу до забезпечення високої доступності систем?
відмовостійкі кластери
Кластери забезпечують можливість усунути конкретну машину як точку збою, захищаючи доступ до вашої базі даних від збоїв обладнання сервера.
Системний кластер складається з двох або більше машин (відомих як вузли), які інтегруються за допомогою апаратного і програмного забезпечення для функціонування в якості єдиної віртуальної машини. У кластері надлишкові апаратне і програмне забезпечення зібрано для забезпечення відмовостійкості: якщо щось піде не так на одному вузлі, або вузол повинен бути переведений в автономний режим для обслуговування, ресурси кластера переключаються на інший вузол для забезпечення безперервного доступу.
Для того щоб бази даних Progress® OpenEdge® могли використовувати кластери в Progress спочатку пропонували окремий продукт Fathom® High Availability Clusters. Згодом ця функціональність була включена в продукт OpenEdge 10В Enterprise і тепер називається просто «відмовостійкі кластери».
Функціональність «відмов кластерів» є незалежною від постачальників операційних систем і апаратного забезпечення. Інтерфейс «відмов кластерів» простий у використанні і значно спрощує адміністрування OpenEdge в кластерному середовищі.
Функціональність «відмов кластерів» не замінює пов'язане з ОС програмне забезпечення для управління кластером, вона просто дозволяє інтегрувати OpenEdge в ваш кластерний менеджер так, що OpenEdge буде правильно визначатися як ресурс кластера. Таким чином, для бази даних включаються можливість адміністрування ресурсів кластера і механізми відмовостійкості, які будуть автоматично забезпечувати відмовостійкість під час запланованого або незапланованого відключення.
Функціональність «відмов кластерів» означає, що підтримка кластерів для баз даних OpenEdge 10 не вимагає від адміністраторів баз даних Progress ставати експертами по кластерам, хоча вони і повинні мати основні знання про кластерний менеджері. Однак, важливо розуміти, що реалізації кластерів є складними, і хтось в організації повинні мати досвід в реалізації і управлінні ними.
З відмовостійкими кластерами адміністратори бази даних просто повинні заздалегідь для себе вирішити, як кластерні ресурси будуть вести себе під час переходу на інший ресурс, встановивши узгоджену політику відмовостійкості, визначальну дії при відновленні, якій повинен автоматично слідувати ресурс і все його залежності, коли виникає стан, вимагає переходу на інший ресурс. Такі політики включають в себе, наприклад, кількість спроб перезапуску бази даних на поточному вузлі, або має чи додаток повертатися назад до використання основного вузла після його відновлення.
Відмовостійкі кластери мають простий інтерфейс командного рядка (PROCLUSTER), який надає доступ до програмного забезпечення кластера вашої операційної системи. PROCLUSTER реєструє ресурси, які повинні бути представлені в кластерному середовищі. З його допомогою ви зможете зареєструвати базу даних як ресурс кластера, однак вам не потрібно визначати залежно для бази даних - функціональність «відмов кластерів» подбає про це за вас.
Функціональність «відмов кластерів» інтегрує OpenEdge в кластер шляхом використання вже існуючого програмного забезпечення менеджера кластерів і відповідного розширення функцій самого OpenEdge. При використанні кластерів ви як і раніше можете використовувати команди PROSERVE або PROSHUT і їх еквіваленти. Ви також можете використовувати PROCLUSTER для запуску і зупинки бази даних. Також для запуску і зупинки бази даних можна використовувати Admin Server. Програмне забезпечення кластерного менеджера операційної системи знає про OpenEdge і буде правильно його обробляти в разі збою.
Якщо змінюється структура бази даних або база даних переноситься на новий пристрій зберігання, PROCLUSTER дозволяє дуже легко зберегти захист бази даних від збоїв. Наприклад, при зміні структури бази даних, що працює в кластері (за допомогою PROSTRCT), функціональність відмов кластерів автоматично визначить, які ресурси потрібно включити, зупинить ресурс, якщо він запущений і відключить і потім знову включить ресурс автоматично.
OpenEdge відповідає моделі безпеки, визначеної постачальником ОС з точки зору того, що користувачі можуть створювати і змінювати; прав доступу до різних каталогах і пристроїв; і прав на запуск і зупинку ресурсів, таких як бази даних.
Продуктивність бази даних не повинна постраждати при використанні кластерів, за винятком додаткового окремого процесу, необхідного для перевірки життєздатності бази даних і повідомлення про це програмному забезпеченню управління кластером.
Для відмов кластерів OpenEdge потрібно, принаймні, двох-вузлова конфігурація, яка використовує архітектуру загального зберігання. Ваша база даних повинна знаходитися на одному або декількох з поділюваних пристроїв (також відомих як загальні сховища).
Найбільш важливою перевагою відмов кластерів є здатність забезпечити простоту використання і обслуговування бази даних в кластері шляхом автоматизації багатьох ручних процедур, які в іншому випадку було б необхідно виконати для забезпечення належного переходу на інший ресурс. Однак слід пам'ятати, що кластеризація не захищає вас від фізичної несправності дисків, на яких знаходиться база даних.
реплікація
Реплікація даних має два основних гідності: можливість поширити копії інформації на один або декількох сайтів і / або забезпечення аварійного відновлення, щоб зберегти постійний доступ до даних для клієнтів. Реплікація OpenEdge автоматично реплицирует зміни з промислової бази даних OpenEdge в базу даних OpenEdge розміщену на резервному сервері.
Реплікація OpenEdge також усуває базу даних як точку збою в середовищі високої доступності.
Таким чином, реплікація OpenEdge надає користувачам можливість підтримувати ідентичність баз даних OpenEdge, забезпечуючи гарячий резерв в разі збою бази даних. Коли відбувається збій бази даних, інша база стає активною. Тому, критично важливі дані завжди доступні для користувачів.
Реплікація OpenEdge забороняє поновлення цільової бази даних будь-якими засобами, відмінними від власне реплікації. Однак, при використанні OpenEdge Replication Plus, цільова база даних відкрита для запитів і звітів користувачів, а також для будь-яких дій, які пов'язані із записом в базу даних (наприклад, для утиліт бази даних). Така конфігурація може значно підвищити продуктивність, дозволяючи формувати звіти та інші дії, пов'язані з інтенсивним читанням на окремих, але однакових базах даних.
Звичайно, вихідна і цільова бази даних можуть знаходитися на одній і тій же машині, але це буде досить безглуздо, так як одним з головних переваг реплікації є те, що цільова база даних буде підключена при аварії машини джерела.
Реплікація OpenEdge підтримує два методи реплікації: синхронний і асинхронний. В асинхронному режимі сервер реплікації OpenEdge відправляє AI-блоки з журналу транзакцій AI агенту реплікації, що працює на цільової базі даних.
У синхронному режимі реплікація OpenEdge блокує подальшу обробку для користувача до тих пір, поки транзакція не буде повністю використана до цільової базі даних.
З двох конфігурацій (синхронної і асинхронної) асинхронна більш продуктивна. Синхронна є найбезпечнішою, але, так як користувач в синхронної моделі блокується, продуктивність стає гірше, ніж в асинхронної моделі.
Щоб гарантувати нормальну роботу реплікації необхідно забезпечити надійний зв'язок по TCP / IP між вихідної і цільової базами даних. Без надійного зв'язку реплікація OpenEdge буде витрачати час на синхронізацію баз даних при відновленні після збою зв'язку, що може призводити до переривання доступу користувачів до баз даних.
В ідеальному світі «високої доступності» ви повинні намагатися реалізувати обидві технології. Вони, по суті, є двома сторонами однієї медалі безперервності бізнесу. Кластеризація мінімізує час простою від відмов комп'ютерів, а реплікація мінімізує час простою від відмов бази даних.
І кластеризація, і реплікація - дуже привабливі варіанти, і дозволяють зробити значний крок на шляху до досягнення кінцевої мети - доступності даних 24/7. З точки зору вартості, реплікація в OpenEdge це окремий продукт, в той час як кластеризація входить до складу ліцензії OpenEdge 10 Enterprise.
Кластерні рішення, підтримувані в OpenEdge (PROCLUSTER)
HPUX (64-bit PA-RISC and Itanium)
- HP software:
- HPUX 11.i or later
- HP mc / ServiceGuard 11.x or later
SUN Solaris Sparc (64-bit)
- SUN software:
- SUN Solaris Sparc 10
- SUN Cluster Version 3.1