Cloud-as-a-Tier, або Як побудувати IT-інфраструктуру за допомогою гібридного хмари

Вибухове зростання приватного і корпоративного контенту визнано однією з найбільш значущих характеристик десятиліття. Згідно з даними журналу «Економіст», у початок 2000-х було створено всього 150 екзабайт (мільярдів гігабайт) контенту, а вже через 10 років цей показник зріс до 1200 екзабайт. Згідно з прогнозами, ця цифра зросте у тисячі разів до 2020 році.

Ми в Cloud4Y вважаємо, що єдиний можливий прогноз щодо вимог до майбутнім сховищ даних   повна непрогнозованість, а також той факт, що їх обсяг буде значно більше того, що тільки можна уявити. Замість того, щоб намагатись керувати цим зростанням, слід змістити фокус на управління «Великим Контентом».


Комунізм в сфері контенту не працює, або думай як Google
Загальний обсяг контенту неухильно зростає. Проте більшість людей дбає тільки про певному робочому наборі» контенту. Наприклад, в SharePoint люди частіше переживають про останніх доданих даних, а якщо мова йде про електронною поштою, нас швидше турбують сьогоднішні листи, а не отримані рік тому.

Традиційною проблемою «Великого Вмісту вважається скромний загальний диск, де зберігається загальний контент. Наприклад, тут може зберігатися корпоративна презентація, і типовий індивід просто бере її, робить «копіпаст», додає пару слайдів від себе і зберігає нову копію. Одні і ті ж слайди пересохраняются знову і знову, при цьому старі презентації нікуди не діваються. Знайомо, чи не так ?

Новою великою проблемою «Великого Вмісту вважаються величезний обсяги відео і інших медіа-засобів. При всьому цьому ми не можемо гребти весь контент під одну гребінку; при роботі з ним слід думати як Google, інакше капітальні та операційні витрати зростатимуть пропорційно обсягам інформації.

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

image
Потенціал хмари і еластичного хмарного сховища
Коли справа стосується зберігання, хмара має деякі незаперечні переваги:
  • Миттєва тонка настройка
  • Неорганиченные здібності масштабування
  • Висока доступність з будь-якого місця в світі
  • Відсутність необхідності в «залізі»
  • Еластичність пам'яті/CPU
  • Зниження витрат у 5–10 разів
Наведемо деякі міфи про хмарних сховищах:
  • Вам доведеться переписати користувальницькі додатки і реорганізувати резервне копіювання, оскільки хмара використовує HTTP/REST API.
  • Вам доведеться зіткнутися з питаннями продуктивності затримок і витрат на смуги пропускання WAN.
  • Оптимізація WAN не працює з публічними хмарами
  • Хмара небезпечно
image
Архітектура Cloud-as-a-Tier: стратегія корпоративного хмарного зберігання
Щоб використати переваги, властиві хмари, потрібно мати архітектуру, призначену для нього. У даній статті будуть розглянуті моделі використання архітектури «Cloud-as-a-Tier» і представлено ідеї про те, як вона може бути використана для організації безпечних багаторівневих корпоративних хмарних систем зберігання даних. Ми розглянемо це в контексті динамічного життєвого циклу контенту в хмарі в порівняно з традиційними способами зберігання, архівації і захисту даних, а також аварійного відновлення.

У якості висновку ми представимо вам модель нової, більш простий корпоративної хмарної архітектури зберігання, яка стане альтернативою для покупки «заліза» і   метою створення:
  • Основного сховища
  • Сховища резервних копій
  • Архівного зберігання
  • Інфраструктури і управління стрічкою даних
  • Реплік даних для аварійного відновлення
  • Віддалених майданчиків для гео-стійкості
image
Тонке виділення ресурсів для «Великого Контенту»
Коли ви плануєте розгортання додатків для «Великого Контенту», основне питання   скільки пам'яті для нього необхідно.

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

Адже, як ми вже сказали введення, «єдиний можливий прогноз щодо вимог до майбутнім сховищ даних   повна непрогнозованість».

Традиційний підхід, вперше випробуваний компанією HP   3PAR, передбачає «Тонке виділення ресурсів», що знімає необхідність у авансовому виділення потужностей. Гібридне хмара виводить цей принцип на новий рівень, дозволяючи компаніям миттєво забезпечувати себе необхідними обсягами для зберігання, оплачуючи тільки використані.

Дедупликация, ранжування даних і автоматичний розподіл по рівнів
Найпростіший приклад, що дозволяє проілюструвати все це   SharePoint. Як ми вже говорили, для користувача властиво змінювати, наприклад, у презентації розміром в 5 Мб тільки ім'я автора і титульний аркуш, зберігаючи обидві версії. Традиційно обидві версії важать 5 Мб; дедупликация змінює цей підхід, представляючи весь інформаційний світ як набір інформаційних блоків. Один і  блок ніколи не зберігається двічі; у нашому прикладі будуть збережені тільки змінені блоки, дозволяючи другої версії презентації займати десятки кілобайт замість 5 Мб.

Погляд на інформаційний світ як на набір блоків і інші переваги. Наприклад, контент, який необхідний постійно, виводиться на передній рівень, а той, який не використовується роками, просто зберігається де задньому плані — все це аналогічно ранжирування сайтів в пошуковику.

Безпека в Cloud-as-a-Tier
Порушення безпеки зазвичай мають на увазі доступ людини до незашифрованим даними. Останні приклади такий: уряд Великобританії зберегло дані про страхування кожного громадянина разом з його банківськими реквізитами та відправило їх в Лондон. Згодом всі ці дані були продані в Інтернеті. Сьогодні складне шифрування даних зробило б ці порушення безпеки неможливими. Безпеки в хмарі — це просто питання виховання.
Є кілька ключових архітектурних питань, які важливі для реалізації захищеного хмари. Всі блоки, які переміщуються від локального сховища до хмари зберігання повинні бути зашифровані як в стані спокою, так і в рух. Другий важливий компонент — це управління ключами: вони повинні зберігатися у замовника, а не в хмарі. Інакше ми знову покладаємося на людини, дозволяючи йому здійснювати доступ до незашифрованному контенту.

Існує додатковий спосіб: агрегований доступ до сховища, коли кожен клієнт має свій власний ключ. Однак продавець   агрегатор, також має доступ до цим ключів   і знову це загроза безпеці.

image

 всі інформаційні блоки однакові
Як ми вже говорили, «Комунізм Контенту» непридатний до хмари: ви не хотіли б, що весь ваш контент перенісся в хмара   вам потрібно щоб зникла з зони видимості невживана його частина. Все, що потрібно для архітектури «Сloud-as-a-tier» — це здатність розуміти поведінку користувачів і адаптувати до нього особливості зберігання.

«Живе» архівування, або «No more Tears with Tiers»
З зростанням обсягів інформації, що зберігається у адміністраторів виникає потреба архівувати її частина і вилучати з живого доступу. Зазвичай це робиться з міркувань економії. При цьому можливі проблеми з міру необхідності в даних: що, наприклад, якщо дані, архівні після шестимісячного простою, терміново необхідні до щорічного звіту?

У системах типу Content Management Systems або SharePoint архівування відбувається ще більш складно, адже необхідно не архівувати лише контент, а також пов'язані з ним політики безпеки і багато іншого. Численні блоки, пов'язані між собою, повинні бути заархівовані таким чином, щоб при необхідності доступ здійснювався до всієї інформації в комплексі.

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

image
Швидке резервне копіювання «Великого Вмісту в хмарі
Хмара не варто розглядати як просто диск глобальної мережі; чинячи так, ви можете отримати сумний досвід, особливо, якщо ви не про резервному копіюванні.

Люди в жартома кажуть: «Який найшвидший спосіб резервного копіювання хмара? Відповідь   просто нічого не робити». Якщо ви зберігайте дані в хмарі, то  є резервне копіювання. Копіюватися для створення резервної версії повинен тільки той контент, який зберігається в даний момент на пристрої   природно, після дедуплікаціі, стиснення і шифрування. Точніше, тільки унікальні блоки інформації такого контенту   досить скромний обсяг.

Швидке відновлення «Великого Контенту» з хмари
Відомо, що люди не дуже замислюються про створення резервних копій   до того моменту, як ці копії можуть знадобитися.

Хмарна архітектура має великий вплив на можливості відновлення даних в первинному або вторинному ЦОД. Якщо ваша резервна версія — це одна велика інформаційна «брила» вагою в кілька терабайт, то відновлення може бути повільним і болючим процесом. Для швидкого відновлення необхідно використовувати можливості «cloud-as-a-tier».

Такий підхід дозволяє зберігати інформацію в багаторівневі структури для зберігання робочого набору на найшвидших SSD і локальних дисках. Архітектура дозволяє раціонально відновлювати мультитерабайтные обсяги — без витягування всього інформаційного обсягу. Витягується тільки невелика кількість даних — «робочий набір», а інші блоки залишаються в хмарі і видаються за міру необхідності. «Робочий набір» створюється заново буквально на льоту, а в цей час повний обсяг даних вже знову на своєму місці.

image
Аварійне відновлення в Cloud-as-a-Tier
Якщо запитати користувачів, як часто вони перевіряють свої процедури аварійного відновлення, вони починають говорити дуже тихо або червоніти. Аварії з своїй натурі непередбачувані. До 11 вересня процедура перенесення записаних збережених даних відбувалася з допомогою літаків, а коли стався ураган Катріна, всі дані залишилися в затоплених шахтах.

З появою хмари виникла можливість регулярно перевіряти політики аварійного відновлення, адже хмара доступно звідусіль і в будь-який момент.

Все, що необхідно — це мати під рукою доступний девайс, на який можна встановити всю конфігурацію. Потім хмарні обсяги можуть знову перенестися для зберігання в віддалене місце, а контент знову стає доступним.

image
«Великий Контент» і віртуальна машина мають одну загальну властивість — вони досить об'ємні. Великі бібліотеки віртуальних машин також можуть зберігатися використанням архітектури «cloud-as-a-tier». Архітектура може застосовуватися як до всієї віртуальній машині, так і просто до сховища даних.

Замість висновку
Традиційний підхід до корпоративного зберігання досить складний особливостей програмного або апаратного забезпечення. Для традиційного підходу необхідно занадто багато факторів.
Гібридне хмара з архітектурою «cloud-as-a-tier» розроблено для використання переваг, притаманних хмари, і спрощення зберігання. Гібридному хмари необхідні лише дві складових:
  • Пристрій для передачі інформації в хмара
  • Хмарний провайдер
Простіше кажучи, хмара дозволяє ранжувати інформацію і зберігати в локальному доступ тільки те, що необхідно на щоденній основі. Ваші локальні програми залишаються на місце   хмара просто інтегрується в існуючу мережу. Ніщо не гарантує такої простоти зберігання «Великого Контенту», як віртуальна машина. Як невеликі планети обертаються навколо величезних, так і «Великий Контент» приверне спритні віртуальні машини, а потім змусить їх рухатися у бік контенту і хмарного провайдера, який управляє контентом.
«Великий Контент» стане новим центром тяжіння, і додатки підуть за ним у хмара.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.