У сучасному цифровому світі очікування безперервного доступу до даних більше не є розкішю - це необхідність.Незалежно від того, чи ви керуєте критичним додатком, поставляєте мультимедійний контент глобальній аудиторії або просто резервуєте персональні файли, надійність вашого хмарного сховища безпосередньо впливає на все, від продуктивності до довіри. Для більшості постачальників хмарної системи надійність оцінюється як відсоток часу роботи — 99,9%, 99,99% або навіть Однак за цими угодами про рівень обслуговування (SLA) лежить жорстка реальність: правда. — можливість отримати доступ до ваших даних в будь-який час, в будь-якому місці, без несподіваних затримок або перебоїв — залишається незрозумілою. Навіть найрозумніші централізовані хмари схильні до того, що вони намагаються пом'якшити: невдачі. five nines continuous performance Надійність - це не те, на що ви сподіваєтеся - це те, для чого ви розробляєте. Від регіональних перебоїв до неправильно налаштованих мережевих маршрутів ми неодноразово бачили, що централізована інфраструктура, незалежно від того, наскільки зміцнена, не може уникнути власних структурних обмежень.Коли всі дороги ведуть через декілька центрів обробки даних, один помилка - пожежа, проблема маршрутизації, внутрішня помилка - може мати вплив на цілі галузі. Від регіональних перебоїв до неправильно налаштованих мережевих маршрутів ми неодноразово бачили, що централізована інфраструктура, незалежно від того, наскільки зміцнена, не може уникнути власних структурних обмежень.Коли всі дороги ведуть через декілька центрів обробки даних, один помилка - пожежа, проблема маршрутизації, внутрішня помилка - може мати вплив на цілі галузі. Цей блог досліджує, чому децентралізована архітектура Sia унікально позиціонується для подолання цих обмежень. У наступних розділах ми порівняємо цей дизайн з традиційними моделями зберігання, розбиваючи реальні сценарії невдач і демонструючи, як децентралізація не тільки безпечніша - вона більш надійна. Виконання завдяки стійкості Тому що в майбутньому хмарного зберігання надійність - це не те, чого ви сподіваєтеся - це те, для чого ви розробляєте. Фрагментарні основи централізованих хмар За всі свої обіцянки "п'яти дев'яти" робочого часу, традиційні хмарні платформи зберігання неодноразово доводили, наскільки крихка централізована інфраструктура може бути, коли стикається з екологічними екстремами, людською помилкою або внутрішніми неправильними конфігураціями.Незважаючи на звільнення, заявлені гіперскалерами, такими як AWS, Google Cloud і Microsoft Azure, реальні дослідження випадків розповідають іншу історію - одну, де мільйони користувачів можуть втратити доступ в мить, і цілі підприємства приводяться до зупинки через єдину точку невдачі. Можливо, найдраматичніші приклади хмарної крихкості можна знайти в пожежах центрів даних — інцидентах, які можуть миттєво вимкнути цілі зони хмарних послуг. У серпні 2022 року електричний вибух в центрі даних Council Bluffs Google поранив трьох працівників і порушив основні послуги, такі як Пошук і Карти. Через рік у Парижі дефіцит кількох кластерів в європейсько-західній зоні Google Cloud почався з вторгнення води – сама по собі це результат несправності системи охолодження, яка заполонила акумуляторну камеру і запалила вогонь. Ці інциденти відображають тепер знамениту пожежу 2021 року OVHcloud в Страсбурзі, яка повністю знищила дата-центр SBG2 і частково пошкодила інші на тому ж кампусі. Many customers had no disaster recovery plans in place, and entire websites were lost without backups. У липні 2022 року рекордно високі температури, що перевищують 40°C (104°F) в Лондоні, зруйнували як центри даних Google, так і Oracle через несправності системи охолодження. Однак не всі перебої народжуються від фізичної катастрофи — деякі з них є цифровими катастрофами, які чекають на те, щоб статися.У лютому 2024 року Google Cloud зазнала ще однієї перебої, коли регіональний збій метаданих складів забрав її регіон із західного регіону близько трьох годин. Аналогічно, рутинне оновлення CrowdStrike в липні 2024 року спричинило поширені аварії систем Microsoft Windows, що призвело до тисяч скасованих рейсів і величезних втрат продуктивності у різних галузях. Коли мережа доставки контенту (CDN) як Fastly зазнала неправильної конфігурації в 2021 році, вона спричинила глобальні розлади, впливаючи на Reddit, Spotify та великі медіа протягом декількох секунд. Постійна продуктивність за дизайном Де централізовані постачальники хмар створюють все більші фортеці для захисту від невдач, Sia повністю усуває проблему, відкидаючи модель фортеці.Замість того, щоб ставити все на стійкість одного регіону або об'єкта, Sia розподіляє ваші дані глобально, по десятках незалежних вузлів, використовуючи математику, а не маркетинг, щоб гарантувати надійність.Це не просто інша інфраструктура - це інша філософія. Звільнення, що дає Звільнення часто розглядається як міра безпеки — спосіб захистити себе від невдач. Але на Sia це набагато більше, ніж це. За замовчуванням Sia розділяє кожен файл на 30 зашифрованих фрагментів за допомогою кодування видалення. Лише 10 з цих фрагментів потрібні для повного реконструкції файлу. Це означає, що мережа може терпіти не тільки перебої, але і змінну продуктивність від окремих хостів - все при збереженні бездоганного доступу. Звільнення - це не провал - це основа безперервної продуктивності. На відміну від того, традиційні хмари покладаються на повне реплікацію файлів у декількох регіонах. Якщо один регіон не вдається, доступ сповільнюється або зупиняється, а додаткове сховище не означає кращу швидкість. Шляхи відновлення змінюються динамічно залежно від доступності хосту та умов мережі — без проваджень, без бар'єрів, без вікон зупинки. І хоча централізовані хмари також можуть використовувати кодування видалення внутрішньо, вся їхня інфраструктура все ще управляється одним провайдером. Хости Sia, навпаки, управляються самостійно — часто різними особами або компаніями.Використання Sia схоже на поділ ваших даних на 30 різних хмар за замовчуванням. Жодна компанія не контролює систему, і жодна точка невдачі не може її знизити. Резистентність без перерви У більшості хмарних середовищ, коли щось руйнується, продуктивність страждає. Навіть при наявності систем провалу, перебої часто призводять до деградації швидкості, заблокованого доступу або загального часу зупинки, коли інфраструктура намагається відновитися. Архітектура компанії працює по-різному. Коли хост, який зберігає частину ваших даних, виходить з Інтернету через несправність, технічне обслуговування або нестабільність, ваші файли залишаються повністю доступними. Немає обертання завантаження, немає затримки синхронізації, немає попередження. Мережа продовжує отримувати необхідні фрагменти від інших хостів, динамічно вибираючи найшвидші доступні варіанти. Тим часом, на тлі, програмне забезпечення орендодавця починає автономно відновлювати повну відпустку, завантажуючи нові фрагменти на здорових господарів. Sia не просто відновлюється від невдачі - вона працює через неї. Замість того, щоб реагувати на невдачу після того, як вона трапляється, Sia розглядає Churn як очікувану поведінку - таку, яку мережа побудована для граціозного поводження. Немає єдиної точки невдачі Централізовані хмарні платформи вразливі до каскадної несправності, тому що вони покладаються на централізований контроль.Неправильно налаштований маршрутизатор, пошкоджене розгортання програмного забезпечення або проблема з живленням в одному об'єкті можуть розповсюджуватися по регіонах - збиваючи послуги, на які мільйони людей покладаються. Архітектура Sia усуває цей ризик за проектом. Немає головного вузла. Немає центрального регіону. Немає привілейованої влади, яка може ненавмисно взяти систему офлайн.Замість цього ваші дані розподіляються по десятках незалежних хостів по всьому світу - кожен з яких зберігає тільки зашифровані фрагменти. Якщо один хост провалився, система продовжує працювати. Якщо десять хостів провалилися, вона продовжує працювати. Немає необхідності «провалитися», тому що немає єдиного шляху, щоб почати. Немає регіону. Немає головного вузла. Немає пляшкового замку. Просто не зупиняється доступ. Ця відсутність центральної залежності не тільки підвищує толерантність до помилок - це Ви не чекаєте, поки регіон повернеться в Інтернет.Ви не заблоковані перевантаженим шлюзом або сервісом відновлення адміністратора людини.Ви витягуєте дані з того місця, де це найшвидше — безперервно. prevents performance blackouts Дизайн для надійності, а не просто сподівання на неї Коли ми говоримо про "надійність хмари", ми часто продаємо обіцянку - SLA, що підтримується фінансовими штрафами, блискучими відсотками часу роботи та репутацією бренду. Але, як ми бачили, навіть найбільші постачальники хмар не можуть уникнути крихкості, яка приходить з централізацією. Замість того, щоб припускати, що інфраструктура зупиниться і підготується до катастрофи, коли вона цього не зробить, Sia припускає, що невдача є неминучою - і будує систему, яка продовжує працювати в будь-якому випадку. Без привілейованих серверів, без регіональних залежностей, без блокування постачальників.Просто саморемонтна, децентралізована інфраструктура, яка тримає ваші дані доступними, тому що жоден з учасників не має сили зробити їх недоступними. Постійна продуктивність Це більше, ніж технічна перевага. Це зміна у тому, як ми думаємо про цифрову стійкість. Замість того, щоб будувати вищі стіни і глибші стелі, Sia розкидає свої оборони. Вона поширює довіру. І, роблячи це, вона переоцінює, як може виглядати надійне хмарне сховище у світі, де час зупинки більше не є прийнятним. Оскільки організації стикаються з зростаючими перебоями, зростаючими витратами та більш жорсткими вимогами до відповідності, децентралізація стала більш ніж життєздатною - це краще. Навіть коли все йде не так, настав час припинити розробляти навколо довіри і почати розробляти навколо певності. Тільки робота З Sia, безперервна продуктивність - це не мета, це гарантія. Джерела Data Center Knowledge. (2022, 9 серпня). Data center fire — Google страждає ‘електричний інцидент’, 3 поранених. Data Center Knowledge. https://www.datacenterknowledge.com/hyperscalers/data-center-fire-google-suffers-electric-incident-3-ранений Claburn, T. (2023, 26 квітня). Облако Google перекидається в Європі посеред витоку води, пожежі. https://www.theregister.com/2023/04/26/google_cloud_outage/ Sverdlik, Y. (2021, 9 березня). Пожежа знищила центр даних OVH в Страсбурзі (SBG2). Знання центру даних. https://www.datacenterknowledge.com/uptime/fire-has-destroyed-ovh-s-strasbourg-datacenter-sbg2 Bloomberg News. (2022, 20 липня). Google, центри даних Oracle потрапили в офлайн через лондонську спеку. Знання центру даних. https://www.datacenterknowledge.com/cooling/google-oracle-data-centers-knocked-offline-by-london-heat Millward, W. (2024, 5 грудня). 10 найбільших хмарних перебоїв 2024. CRN. https://www.crn.com/news/cloud/2024/the-10-biggest-cloud-outages-of-2024 Барретт, Б. (2021, 8 червня). Як незрозуміла компанія забрала великі шматочки інтернету. WIRED. https://www.wired.com/story/fastly-cdn-internet-outages-2021/

This story contains new, firsthand information uncovered by the writer.

Це аудіо створено мовою оригіналу історії!

Надто довго; Читати

Make resilience your competitive advantage

Sia переоцінює надійність хмари за допомогою безперервної продуктивності

About Author

КОМЕНТАРІ

ПОВІСИТИ БИРКИ

ЦЯ СТАТТЯ БУЛА ПРЕДСТАВЛЕНА В

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps