:: ECONOMY :: МЕХАНІЗМИ ПОБУДОВИ ВІДМОВОСТІЙКОГО КЛАСТЕРУ І БЕКАПУВАННЯ  БАЗ ДАНИХ :: ECONOMY :: МЕХАНІЗМИ ПОБУДОВИ ВІДМОВОСТІЙКОГО КЛАСТЕРУ І БЕКАПУВАННЯ  БАЗ ДАНИХ
:: ECONOMY :: МЕХАНІЗМИ ПОБУДОВИ ВІДМОВОСТІЙКОГО КЛАСТЕРУ І БЕКАПУВАННЯ  БАЗ ДАНИХ
 
UA  RU  EN
         

Світ наукових досліджень. Випуск 33

Термін подання матеріалів

19 вересня 2024

До початку конференції залишилось днів 12



  Головна
Нові вимоги до публікацій результатів кандидатських та докторських дисертацій
Редакційна колегія. ГО «Наукова спільнота»
Договір про співробітництво з Wyzsza Szkola Zarzadzania i Administracji w Opolu
Календар конференцій
Архів
  Наукові конференції
 
 Лінки
 Форум
Наукові конференції
Наукова спільнота - інтернет конференції
Світ наукових досліджень www.economy-confer.com.ua

 Голосування 
З яких джерел Ви дізнались про нашу конференцію:

соціальні мережі;
інформування електронною поштою;
пошукові інтернет-системи (Google, Yahoo, Meta, Yandex);
інтернет-каталоги конференцій (science-community.org, konferencii.ru, vsenauki.ru, інші);
наукові підрозділи ВУЗів;
порекомендували знайомі.
з СМС повідомлення на мобільний телефон.


Результати голосувань Докладніше

 Наша кнопка
www.economy-confer.com.ua - Економічні наукові інтернет-конференції

 Лічильники
Українська рейтингова система

МЕХАНІЗМИ ПОБУДОВИ ВІДМОВОСТІЙКОГО КЛАСТЕРУ І БЕКАПУВАННЯ БАЗ ДАНИХ

 
14.05.2024 13:15
Автор: Вінічук Олександр Сергійович, заступник начальника відділу супроводження платформи сервіс-деск, АТ "Ощадбанк", м. Київ
[2. Інформаційні системи і технології;]


Хмарні обчислення або скорочено хмара — модель забезпечення повсюдного та зручного доступу на вимогу через мережу до спільного пулу обчислювальних ресурсів, що підлягають налаштуванню (наприклад, до комунікаційних мереж, серверів, засобів збереження даних, прикладних програм та сервісів), і які можуть бути оперативно надані та звільнені з мінімальними управлінськими затратами та зверненнями до провайдера.

Дата-центр або Центр даних — приміщення у споруді, будівля або група будівель, призначена для збирання, нагромадження й зберігання великих обсягів інформації та їх опрацювання. Обчислення здійснюють комп'ютери високої продуктивності та їх пристрої введення та виведення інформації, які за допомогою Інтернету здійснюють обмін інформації між центром даних і зовнішнім середовищем.

Комплексна система захисту інформації (КСЗІ) — взаємопов'язана сукупність організаційних та інженерно-технічних заходів, засобів і методів захисту інформації.

Велика кількість середнього і великого бізнесу використовують ЦОД для роботи і зберігання великих баз даних які зберігають інформацію увесь час скільки працює компанія. Хмарні середовища надають послуги по збереженню і обробці даних на своїх потужностях. 

В наш час є велика кількість вірусів які можуть легко потрапити в мережу компанії або хмарного середовища і тим самим зашифрувати файли в тому числі файли баз даних, що призведе до втрати даних і зупинки підприємства. Особливо актуально стоїть питання втрати даних  в Україні в якій вже 3 рік триває повномасштабна війна.

Для збереження даних обов’язково потрібно щоб було 2 сервери баз даних, бажано рознесених на різні ЦОД. Між цими серверами можна реалізувати механізми синхронізації які зможуть частково або повністю синхронізувати дані. 

Перший варіант це побудова відмовостійкого кластеру серверів баз даних на базі групи доступностіAlwaysOn, які працюють в режимі Active – Active.




Даний кластер із двох баз даних працює паралельно. Тобто транзакції виконуються одночасно на основній і резервній базі даних. При цьому СУБД сама вирішує який саме сервер буде активний. У разі втрати працездатності основної БД робота буде відразу переключена на резервний сервер баз даних. Але в даному варіанті є як і плюси, у вигляді відмовостійкості і відсутності втрати даних, так і мінуси. Основним мінусом являється швидкість мережі у випадку роботи серверів баз даних на різних ЦОД. Так якщо основний сервер працює на ЦОД в Києві, а інший на ЦОД у Львові то швидкість мережі суттєво вплине швидкодію кластеру серверів БД, і даний фактор слід врахувати і щоб не стикнутися з повільною швидкодією інформаційної системи можливо слід використати інші варіанти синхронізації серверів баз даних.

Наступний режим роботи двох БД називається Active – StandBy. Причому резервна БД працює в режимі StandBy/ReadOnly. 




Даний механізм синхронізації працює за допомогою доставки журналів транзакцій (англ. Transaction log shipping). Під час його активації у властивостях самої бази даних на основному сервері БД створюється бекап який розгортається на резервний сервер баз даних, після чого на основному сервері створюється задача в планувальнику на бекапування збережених транзакцій в лозі БД в окремий файл, а на резервному створюються задачі на копіювання даного бекапу транзакцій на резервний сервер і виконання даних транзакцій на резервній БД. Дані задачі працюють за допомогою планувальника SQL Agent. За замовченням даний механізм налаштовано на запуск раз в 15 хв. Спочатку створюється бекап транзакцій із лог файлу, які копіюються на резервний сервер і потім дані транзакції виконуються на резервному сервері баз даних. У разі втрати працездатності основної БД необхідно резервну БД вивести із режиму StandBy шляхом відновлення з логу, а інформаційну систему  вручну переключити на резервну. Даний процес займатиме не більше 30 хв, після чого роботу інформаційної системи буде відновлено. Даний метод не впливає на швидкодію кластеру баз даних, але, у випадку втрати працездатності основної БД, існує ризик втрати даних за останні 15 хв, а також для відновлення працездатності інформаційної системи на резервній БД потрібен час приблизно 30 хв.

Останній метод синхронізації це механізм реплікацій.

 

Даний метод реалізований на основі публікації реплікацій основним сервером. Основний сервер публікує транзакції, а резервний сервер підписується на публікації основного серверу і забирає публікації. Тобто основний сервер - це сервер видавець, а резервний сервер – це сервер підписник. Причому реплікувати можна не всі таблиці або види бази даних, а лише деякі. Даний механізм також працює раз в 15 хв. за замовченням. У випадку втрати працездатності основної БД потрібно відписати резервну базу даних від публікацій основної бази і переключити роботу інформаційної системи на резервний сервер баз даних. Дані роботи займають не більше 15 хв. часу. Із позитивних сторін даного методу це можливість репліціювати лише деякі таблиці чи види в БД, а також відсутність будь-якого впливу на швидкодію кластеру. Із недоліків це ризик втрати даних за останні 15 хв. у випадку втрати працездатності основного серверу, і необхідно вручну відписати резервну БД від бази видавця і переключити роботу інформаційної системи на резервну базу даних.

Обов’язково на обох серверах повинно бути налаштовано бекапування даних вночі, і завантаження копій бекапу в хмарні середовища, бажано в декілька копій. Для цього можна налаштувати план обслуговування БД який відключить всіх користувачів від БД і запустить процес створення бекапа. Під час налаштування даного плану можна вручну вибрати час коли почати створювати бекап. Як правило вибирають між першою і третьою годиною ночі, коли мінімальне навантаження на сервер.

Хмарні технології, великі бази даних, віртуальні машини це теперішнє і майбутнє будь-якого бізнесу і IT-сфери в цілому, а тому важливо побудувати відмовостійкий кластер серверів баз даних для попередження втрати працездатності баз даних і інформаційних системи підприємства. А також налаштувати бекапування на основній і резервних базах даних  щоб зберегти дані у випадку втрати працездатності ЦОД або хакерської атаки. Бажано в хмару складати декілька копій бекапів. Це допоможе відновити дані підприємства і застрахувати його від IT-угроз.

Список використаних джерел

1. Про основні засади забезпечення кібербезпеки України : Закон України від 05.10.2017 р. № 45. URL: http://surl.li/towfr (дата звернення: 10.05.2024)

2. Розгортання MS SQL - http://surl.li/towef  (дата звернення: 10.05.2024)

3. Відмовостійкий кластер БД AlwaysOn MS SQL SERVER - http://surl.li/tfsox  (дата звернення: 10.05.2024)

4. Transaction log shipping MS SQL SERVER - http://surl.li/tfspy (дата звернення: 10.05.2024)

5. Configure replication between two fully connected servers - http://surl.li/tfsqq  (дата звернення: 10.05.2024)

6. Replication Publishing Model Overview - http://surl.li/tfsrx  (дата звернення: 10.05.2024)

7. Create a Full Database Backup - http://surl.li/tfsss (дата звернення: 10.05.2024)



Creative Commons Attribution Ця робота ліцензується відповідно до Creative Commons Attribution 4.0 International License

допомогаЗнайшли помилку? Виділіть помилковий текст мишкою і натисніть Ctrl + Enter


 Інші наукові праці даної секції
ОСНОВНІ ПРИНЦИПИ ТРИВИМІРНОГО МОДЕЛЮВАННЯ
28.05.2024 00:18
ОСОБЛИВОСТІ ТЕХНІЧНОГО ЗАХИСТУ АВТОРСЬКИХ ПРАВ ЗА ДОПОМОГОЮ ВИКОРИСТАННЯ СТЕГАНОГРАФІЇ (НА ПРИКЛАДІ КОМП’ЮТЕРНИХ ІГОР)
27.05.2024 18:03
ВИКОРИСТАННЯ ПОТОЧНОГО СТАНУ ТА ПЕВНИХ ТЕНДЕНЦІЙ У ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЯХ ДЛЯ ПРОГНОЗУ
27.05.2024 16:36
ВИЗНАЧЕННЯ ТИПУ ДАНИХ ЗА ДОПОМОГОЮ НЕЙРОННИХ МЕРЕЖ
22.05.2024 12:14
СТВОРЕННЯ МОБІЛЬНОГО ЗАСТОСУНКУ ДЛЯ КЕРОВАНОГО СИНТЕЗУ ФОТОРЕАЛІСТИЧНИХ ЗОБРАЖЕНЬ
21.05.2024 13:16
РОЛЬ ШТУЧНОГО ІНТЕЛЕКТУ ЗАДЛЯ ЕФЕКТИВНОГО МЕНЕДЖМЕНТУ IT КОМПАНІЙ
21.05.2024 13:03
МЕТОДИКА ВИЯВЛЕННЯ DDOS-АТАК НА ОСНОВІ АЛГОРИТМУ ДЕНДРИТНИХ КЛІТИН
17.05.2024 16:23




© 2010-2024 Всі права застережені При використанні матеріалів сайту посилання на www.economy-confer.com.ua обов’язкове!
Час: 0.356 сек. / Mysql: 1512 (0.286 сек.)