Програмний комплекс для управління необмеженою кількістю хмарних сховищ
24.04.2019
Програмний комплекс для управління необмеженою кількістю хмарних сховищ
Вступ
Постановка проблеми. У наш час, розвиток цифрових технологій не стоїть на місці. І щоб відповідати сучасним стандартам потрібно постійно вдосконалювати обладнання і методи зберігання інформації. Також, постійно виникає питання зручності та доступності використання даних. Дані можуть зберігається в локальних сховищах, на жорстких дисках комп'ютерів, на переносних пристроях або в хмарних сервісах. Зберігання даних в хмарах вирішує питання зручності та доступності, тому що в такому випадку дані стають доступні з будь-якої точки світу, де є підключення до Інтернету.
В такому випадку, всі дані зберігаються на віддалених серверах, а користувач, маючи гарну швидкість Інтернету, може працювати з ними так, ніби вони перебувають у нього на комп'ютері.
Способи організації хмарного сховища бувають різні, але суть у всіх одна – надати користувачу віддалений доступ до даних. Хмарні сервіси бувають, публічними, приватними або гібридними. Приватні сервіси дозволяють користувачу налаштувати хмарне сховище повністю під себе, легко регулюючи обсяги і будь-які інші параметри, такі як пропускна здатність і тому подібне. Публічні сервіси накладають обмеження на управління хмарою і завжди мають обмежений безкоштовний обсяг пам'яті. Гібридні ж, в свою чергу, об'єднують в одну систему і приватні і публічні хмари з метою балансування навантаження на приватне сховище, за рахунок використання публічного, або для резервного копіювання деяких даних.
Існує багато онлайн сервісів, які надають безкоштовно деякий обсяг простору. Зазвичай, це близько 10 гігабайт, і щоб використовувати більший обсяг простору треба платити щомісяця, в середньому, близько 10 доларів. До недоліків існуючих методів збереження інформації у хмарах можна віднести надійність, своєчасність отримання і доступність даних в «хмарі», яка дуже сильно залежить від багатьох проміжних параметрів, таких як: канали передачі даних на шляху від клієнта до «хмари», надійність останньої милі, якість роботи Інтернет провайдера клієнта, доступність самої «хмари» в даний момент часу. Також до недоліків можна віднести щомісячну абонентську плату за використання сервісів, а також загальну продуктивність при роботі з даними в «хмарі», яка може бути нижче, ніж при роботі з локальними копіями даних.
Основним шляхом усунення зазначених недоліків є вдосконалення технології хмарного збереження даних, за рахунок балансування заповнення хмарних сховищ інформацією. Також, для покращення швидкості праці з файлами, вводиться кешуваня файлів, доступ до яких найчастіший. Для вирішення проблем з абонентською платою можна використовувати цей програмний комплекс.
Метою статті є дослідження можливості оптимізації і спрощення управління процесом збереження даних з використанням необмеженої кількості хмарних сховищ.
Результати розробки та досліджень
Для розробки програмно комплексу управління процесом збереження даних було використано два хмарних сервіси: Google Drive та Mega.
Google Drive - це служба зберігання і синхронізації файлів, розроблена компанією Google [5]. Google Диск дозволяє користувачам зберігати файли на своїх серверах, синхронізувати файли на різних пристроях і обмінюватися файлами. Google Диск пропонує користувачам 15 гігабайт безкоштовного сховища та інші розміри, пропоновані за допомогою додаткових платних планів. Щоб підключити аккаунт до системи, потрібно включити використання API для аккаунта [6], створивши ідентифікатор клієнта OAuth 2. Після цього, аккаунт можна додавати до програми разом з раніше створеним файлом ідентифікатора.
MEGA - файлообмінник з шифруванням даних [7]. Mega шифрує весь контент прямо в браузері за допомогою алгоритму AES. Користувачі можуть передавати один одному файли в зашифрованому вигляді, при цьому всі дані зберігаються в «хмарі». Mega надає 15 ГБ безкоштовного розміру (50 ГБ перший місяць користування), а також інші платні плани для збільшення розміру сховища. Підключення до програми виконується додаванням логіну и паролю від аккаунту до програми.
Для об’єднання сховищ у єдину систему, спочатку потрібно було вирішити питання зберігання даних, у якому виді зберігати, та відображувати файли. Зберігати файли було вирішено у тому виді, в якому вони завантажувалися з хмарних сервісів – у види списків. Відображувати файли, було вирішено, в одному з найпоширеніших способів – в виді дерева. Кожен файл має в собі інформацію про «родичів», тому легко можна створити дерево. Дерево створюється рекурсивно, виконуючи пошук для кожної папки кореневого каталогу його дітей, та створення нової гілки, після цього рекурсивно виконується пошук дітей для кожного попереднього елемента і так далі, поки дерево не буде створено.
При об’єднанні сховищ, ми будемо використовувати раніше створені дерева для кожного сховища. Об’єднання сховищ робиться теж рекурсивно, як і створення дерев. При об’єднанні не створюється нового дерева, а додаються нові гілки у дерево головного сховища (яке було обрано заздалегідь). Завдяки цьому не потрібно рекурсивно продивлятися усі гілки сховища, з яким робиться об’єднання, тому що, при додаванні у головне дерево, додається гілка з усією своєю структурою і дітьми.
Алгоритм об’єднання:
1. Перевіряємо чи є у кореневому каталогу головного сховища папка с такою ж назвою, як і в сховищі донорі.
2. Якщо така папка існує, то робимо помітку в структурі цієї папки головного сховища, указуючи, що вона належить обом сховищам (додаємо логін сховища, якому вона теж належить) і переходимо до шагу №3. Якщо ж, такої папки не існує, просто додаємо її до головного сховища і переходимо порівнювати іншу папку сховища донора з папкою сховища реципієнта.
3. Рекурсивно передаємо дітей обох сховищ (головного і донора) до цього методу, тобто повертаємося на шаг №2, але вже порівнюємо дітей, тобто спускаємося на рівень вниз по дереву. Коли ми дійдемо до кінця дерева, тобто дітей не залишиться, алгоритм закінчуються.
Об’єднання дерев робиться доки не буде зроблено об’єднання з усіма деревами. Після цього, на екран користувача виводиться одна єдина структура дерева, з папками з усіх сховищ.
Алгоритм загрузки файлів у сховища складається з двох етапів. Перший, це користувач обирає необхідні файли для відправлення у сховища, та перетягує їх у зони відправлення файлів рис. 1, у якій вони відображуються після додавання.
Рисунок 1 - Файли у зоні відправлення
Після цього, настає другий етап. Оцінка сховища, у яке буде відправлено файли. Етап ґрунтується на оцінці проценту вільного простору на диску. Оцінюється не розмір вільної пам’яті, а процент вільного простору, тому що у хмарних сервісів може бути різний розмір пам’яті яку, вони надають користувачу. Таким чином легко можна балансувати загрузку даними усі сховища.
На рисунку 2, можна побачити завантаженість даними у процентному відношенні сховищ, які використовуються у програмі, а у таблиці 1, наведено інформацію про вільне місце у гігабайтах.
Рисунок 2 - Стан сховищ до завантаження файлів
Таблиця 1. Стан простору сховищ до завантаження файлів
|
Сховище |
Вільний простір, ГБ |
Занятий простір, ГБ |
|
Mega |
14 |
1 |
|
Google Drive |
12 |
3 |
|
Mega 1 |
15 |
0 |
|
Google Drive 1 |
10 |
5 |
|
Mega 2 |
11 |
4 |
Після того, як було отримано інформацію про завантаженість сховищ, файли починаються відправлятися до сховищ, див. рис. 3.
Рисунок 3 - Почергове відправлення файлів у сховища
Після відправлення 7 файлів розміром 2 ГБ, 3 ГБ, 4 ГБ, 4 ГБ, 5 ГБ, 3 ГБ, 2 ГБ, наповненість сховищ виглядає наступним образом, див. рис. 4, а у таблиці 2, можна побачити стан розміру сховищ після завантаження файлів.
Рисунок 4 - Стан сховищ після завантаження файлів
Таблиця 2. Стан простору сховищ після завантаження файлів
|
Сховище |
Вільний простір, ГБ |
Занятий простір, ГБ |
|
Mega |
9 |
6 |
|
Google Drive |
8 |
7 |
|
Mega 1 |
9 |
6 |
|
Google Drive 1 |
5 |
10 |
|
Mega 2 |
8 |
7 |
Можна побачити, що алгоритм розподілення даних по сховищам, майже рівномірно заповнив усі сховища файлами. На етапі відправлення 5-го та 6-го файлів декілька сховищ мали рівний вільний обсяг, але файли були відправлені до сховища Google Drive 1 та Mega 2 відповідно, тому що до цього моменту, туди нічого не відправлялося.
Алгоритм оцінки вільного простору при відправлені файлів було обрано, тому що для балансування завантаженості всіх сховищ, які підключені до програми, цей спосіб є оптимальним. Він надає можливість рівномірно розподіляти данні, та допомагає зменшити вплив однієї з проблем використання хмарних сховищ, а саме – проблему недоступності сховища. Коли данні розподілені рівномірно, то зменшується шанс втратити усю інформацію, як в ситуації якщо вона би зберігалася лиш на одному сховищі. При недоступності хмарного диску (технічні проблеми, загублення паролю) ми будемо мати доступ до інших сховищ, і до інформації яка там розподілена.
Також, було розроблено алгоритм балансування розподілення даних, в разі, коли додається новий аккаунт до системи. Алгоритм надає можливість збалансувати навантаження на усі сховища, якщо один з аккаунтів перевантажений, чи вільний.
Добавимо до нашої системи повністю заповнений аккаунт Google Drive сховища, див. рис. 5, в табл. 3 приведено стан розміру сховищ після додавання аккаунту.
Рисунок 5 - Процент наповненості сховищ після додавання нового аккаунту
Таблиця 3. Стан простору сховищ після додавання нового аккаунту
|
Сховище |
Вільний простір, ГБ |
Занятий простір, ГБ |
|
Mega |
9 |
6 |
|
Google Drive |
8 |
7 |
|
Mega 1 |
9 |
6 |
|
Google Drive 1 |
5 |
10 |
|
Mega 2 |
8 |
7 |
|
Google Drive 2 |
0 |
15 |
S = M/N (1)
де M – розмір даних, які потрібно розподілити по сховищам, а N – кількість хмарних сховищ.
Після того, як розмір даних які потрібно відправляти у кожне сховище розраховано, починається відправка файлів до інших сховищ. Вона робиться доки, завантаженість хмарних дисків не буде майже рівною. За формулою, програма буде розподіляти ко сховищам по 2 ГБ даних. Схематичний процес балансування зображено на рис. 6.
Рисунок 6 - Схематичне зображення балансування
Результат балансування див. на рис. 7, а у таблиці 4, можна побачити стан розміру сховищ після балансування.
Рисунок 7 - Стан сховищ після балансування файлів
Таблиця 4. Стан простору сховищ після балансування даних
|
Сховище |
Вільний простір, ГБ |
Занятий простір, ГБ |
|
Mega |
7 |
8 |
|
Google Drive |
6 |
9 |
|
Mega 1 |
7 |
8 |
|
Google Drive 1 |
5 |
10 |
|
Mega 2 |
6 |
9 |
|
Google Drive 2 |
7 |
8 |
В результаті балансування, дані були відправлені в Mega 1 – 2 ГБ, Mega – 2 ГБ, Google Drive – 2 ГБ, та Mega 2 – 2 ГБ.
Висновки
В роботі виконано розроблення програмного комплексу для управління необмеженою кількістю аккаунтів хмарних сервісів Google Drive та Mega. На рис. 8 зображено інтерфейс програми.
Рисунок 8 - Інтерфейс програмного комплексу для управління сховищами
Обґрунтовано вибір алгоритму управління процесом збереження даних.
Удосконалено існуючі алгоритми збереження даних у хмарних сховищах за рахунок можливості об’єднання необмеженої кількості аккаунтів сховищ, та балансування завантаженості кожного за рахунок алгоритму процентного відношення місця у сховищах.
Був розроблений та реалізований алгоритм поєднання сховищ, для зручного управління та відображення файлів користувачу.
Розроблено алгоритм балансування завантаженістю даними сховищ, при додаванні нового аккаунти, як чистого так і вже заповненого. Балансування можна виконати за бажанням користувача.
Проведені дослідження підтверджують, що така організація сховищ, підвищую стабільність збереження даних, а також надає можливість мати великий розмір хмарного сховища безкоштовно.
Назва конкурсу: Конкурс «Кращий інноваційний диплом (проект)»
ПІБ конкурсанта: Пасько Денис Андрійович
Країна: Україна
Область: Харківська область
Назва НЗ: Національний технічний університет «Харківський політехнічний інститут»
Учасник фіналу: Так
Файл статті (pdf): Завантажити
