У цій трилогії ми розкриємо технологічні досягнення, які можуть суттєво поліпшити обробку даних для програм, що працюють на Інтернет-комп'ютерному протоколі (ICP).
Це оновлення є віхою Stellarator в дорожній карті ICP, наразі воно розгортається по всій мережі, Stellarator є проривом у зберіганні даних на ланцюзі, що дозволяє кожній підмережі містити понад 1 ТБ пам'яті, що відкриває можливості для насичених даними додатків, які раніше були обмежені зберіганням.
Цей прогрес дозволяє розробникам створювати складні програми, які потребують обробки великих обсягів даних, що приносить новий рівень практичності для блокчейн-технологій.
Не гаючи часу, давайте почнемо цю серію та подивимося, як ICP зараз використовує оновлення Stellarator для зберігання даних.
Постійність даних в Інтернет-комп'ютері
Цей блог дає огляд того, як працює зберігання на машинах копій Інтернет-комп'ютера, зосереджуючи увагу на нещодавно впроваджених змінах на основі дерев з журналом та об'єднанням (LSMT), які включають реалізацію більшого обсягу копій зберігання в підмережах Інтернет-комп'ютера та дозволяють їм краще обробляти важкі навантаження.
Інтернет-комп'ютер складається з підмереж і віртуальних машин, які виконують однакове копіювання на 13-40 машинах копій, кожна копія відповідає за виконання всіх повідомлень, надісланих до цієї підмережі, та зберігає всі дані контейнерів, тому всі копії мають повний і однаковий стан підмережі.
Розробники можуть розгорнути контейнери в Інтернет-комп'ютері, контейнери схожі на смарт-контракти на інших блокчейнах, але можуть виконувати більш універсальні обчислення та зберігати даних на порядки більше, ніж смарт-контракти на інших ланцюгах.
Дані, що зберігаються в контейнерах, в кінцевому підсумку потрібно зберігати на певному фізичному апараті, завдяки нещодавно впровадженому шару зберігання на основі LSMT, а також багатьом іншим оптимізаціям та покращенням, підмережі Інтернет-комп'ютера можуть зберігати дані контейнерів обсягом до 1 ТБ.
Більшість даних контейнера зберігається або у його купчастій пам'яті (до 4 ГБ під час запису), або в його стабільній пам'яті (до 500 ГБ під час запису), також існують інші форми даних, пов'язаних з контейнером, такі як код контейнера, повідомлення в процесі та різноманітна інформація, така як список контролерів та баланси циклів.
Шар зберігання ICP усуває розрив між зберіганням контейнерів (наприклад, купчастою та стабільною пам'яттю) та апаратним зберіганням підлягаючих машин копій (наприклад, дисками та RAM).
У рамках досягнення Stellarator шар зберігання зазнав значних перепроектувань та повторної реалізації, щоб ICP міг впоратися з майбутніми викликами масштабованості та вирішити найбільш важливі вузькі місця масштабованості старого шару зберігання, всі відповідні зміни були завершені нещодавно, Інтернет-комп'ютер вже кілька місяців працює з новою реалізацією шару зберігання.
У решті цього блогу описано процес перепроектування шару зберігання в структуру даних журналу та об'єднання, перепроектування має на меті усунути вузькі місця, пов'язані з зберіганням, та покращити досвід користувачів і розробників, які використовують ресурсоємні контейнери.
Для користувачів ICP найбільш помітним є те, що ця робота дозволила нещодавно збільшити копійований стан в межах одного підмережі до 1 ТБ, крім того, перепроектування також дозволило Інтернет-комп'ютеру краще обробляти контейнери, що записують великі обсяги даних.
Контрольна точка
Загалом, шар зберігання Інтернет-комп'ютера поєднує постійне зберігання на диску та тимчасове зберігання в RAM, одним з ключових концептів того, як Інтернет-комп'ютер зберігає свій стан, є так звана контрольна точка, контрольна точка - це логічний момент часу, в який весь стан підмережі зберігається на диску.
Контрольна точка створюється кожні 500 блоків або кожні кілька хвилин у детермінованому режимі, що означає, що всі копії записуватимуть однакову контрольну точку на однаковій висоті, контрольні точки зберігаються у вигляді файлової директорії на диску кожного вузла копій, структура директорії виглядає так (значно спрощено):
У цій структурі кожен контейнер зберігається у власному підкаталозі, і кожен каталог контейнера містить окремі файли для купчастої пам'яті, стабільної пам'яті та іншої інформації (такої як повідомлення в процесі), дані зберігаються на диску у вигляді контрольних точок з різних причин.
1. Постійність даних: машини копій можуть перезавантажуватися в будь-який момент, у коді копій можуть бути програмні помилки, або може бути проблема з обладнанням, або з електропостачанням у дата-центрі, у разі виникнення таких ситуацій можна знову завантажити останню контрольну точку.
Зверніть увагу, що навіть якщо контрольні точки створюються лише кожні 500 раундів, копії можуть відновити стан для висот, які не є контрольними точками, копії потрібно лише остання контрольна точка і всі остаточні блоки між контрольними точками та останнім станом, оскільки всі виконання є детерміністичними, ці блоки можуть бути повторно відтворені, і гарантовано відновлений стан буде точно таким же, необхідні блоки можуть бути окремо збережені з контрольних точок на диску або отримані з інших копій.
2. Синхронізація: всі (копійовані) повідомлення виконуються всіма копіями, тому для будь-якої даної висоти h усі копії повинні мати однаковий стан, протокол запобігає розбіжностям (тобто, коли деякі чесні копії в кінцевому підсумку опиняються в стані, відмінному від консенсусного стану), спочатку хешуючи стан, а потім підписуючи згенерований хеш з пороговим значенням, таке порогове підписання може бути створене лише тоді, коли принаймні ⅔ (точніше 2f + 1) копій погоджуються з однаковим хешем, тільки тоді підмережа може продовжити роботу.
Однак підмережі Інтернет-комп'ютера можуть мати більший стан, на момент написання обмеження становить 1 ТБ, при цьому зберігаючи не більше 2,5 блоків за секунду (що в даний час є найшвидшим підмережею Інтернет-комп'ютера), хешувати стільки даних після кожного блоку є неможливим, отже, Інтернет-комп'ютер хешує лише вибрану частину стану, що не є контрольними точками, наприклад, деяку основну інформацію про кожен контейнер, нещодавні відповіді на вхідні повідомлення та повідомлення XNet, надіслані до інших підмереж.
Для контрольних точок протокол хешує весь стан, щоб отримати так звану структуру даних під назвою список, цей список обчислюється шляхом хешування всіх файлів у каталозі контрольних точок і містить хеші всіх окремих файлів, розбитих на блоки по 1 МБ, в кінці обчислення списку обчислюється кореневий хеш списку, що охоплює всі окремі хеші у списку, а потім підмережа підписує його порогом, обчислення списку може зайняти десятки секунд, але ця робота виконується лише кожні 500 блоків і виконується паралельно з виконанням контейнера в фоновому режимі.
3. Синхронізація стану: Інтернет-комп'ютер дозволяє змінювати топологію підмережі за допомогою пропозицій NNS, коли вузли копій приєднуються до підмережі, вони можуть отримати останню контрольну точку від інших вузлів копій, нагадаємо, що контрольна точка - це набір файлів, тому після перевірки його кореневого хешу та підпису на список з пороговим значенням підмережі, протокол синхронізації стану може отримувати файли по частинах, при цьому порівнюючи хеші отриманих частин з хешами у списку, якщо всі перевірки успішні, копія може дійти висновку, що отриманий стан відповідає погодженому стану окремих підмереж на висоті контрольної точки, якщо копія відстає з інших причин, і різниця з нормальним станом занадто велика, щоб наздогнати чисте повторення блоків, також буде викликано синхронізацію стану.
4. Максимальний розмір стану: в даний час максимальний розмір стану становить 1 ТБ, а RAM на машинах вузлів копій - 512 ГБ, тому неможливо завантажити весь стан у RAM, Інтернет-комп'ютер використовує RAM переважно для зберігання останніх даних, які ще не були збережені, а також для кешування даних для підвищення продуктивності.
PageMap та висоти, що не є контрольними
Оскільки контрольні точки створюються лише кожні 500 блоків, ICP потрібно надати різний обсяг пам'яті для стану, не є контрольними точками, основна ідея, якої дотримується шар зберігання, полягає в тому, що ці дані зберігаються у формі комбінації останньої контрольної точки, будь-які зміни, що відбуваються після цього, зберігаються в RAM.
PageMap - це реалізація більшості вмісту стану підмережі копій, більшість стану підмережі є станом контейнерів, зокрема, купчастою та стабільною пам'яттю контейнерів.
На даний момент контейнери можуть мати до 4 ГБ купчастої пам'яті, 500 ГБ стабільної пам'яті, а загальний ліміт стану підмережі становить 1 ТБ, але всі ці обмеження можуть змінитися в майбутньому, обидва типи пам'яті можна читати через виклики контейнерів з копіюванням (оновлення) та без копіювання (запити), а також можна модифікувати через виклики копій.
Структура даних PageMap призначена для забезпечення ефективного читання та запису в пам'ять, а також для підтримки ефективного запису контрольних точок, однією з конкретних цілей є зробити продуктивність незалежною від загального обсягу пам'яті, зверніть увагу, що назва PageMap походить від того факту, що всі елементи читання та запису мають розмір 4 КБ, що відповідає розміру сторінок, що використовується підлягаючою операційною системою.
PageMap зберігає стан у двох шарах: перший шар, званий зберіганням, - це файли з попередньої контрольної точки, які представляють стан на висоті попередньої контрольної точки, другий шар, тобто інкременти сторінок, представляє всі зміни з моменту цієї контрольної точки та зберігається в RAM.
При зчитуванні з PageMap дані повертаються або з інкрементів сторінок, або з контрольних файлів (якщо відсутні), запис у PageMap здійснюється шляхом зміни інкрементів сторінок новими даними.
Життєвий цикл контрольних точок
Основним завданням шару зберігання є запис контрольних точок на диск і підтримка всіх PageMap у актуальному стані, при запису нової контрольної точки всі інкременти сторінок скидаються на диск, оновлюючи збережену частину всіх PageMap.
Щоб гарантувати, що всі дані зберігаються, копії завжди повинні зберігати найновішу контрольну точку, яка підписана порогом, це означає, що неможливо просто перезаписати старі контрольні файли, оскільки будь-які такі зміни змінять попередню контрольну точку до повного запису нової контрольної точки, що створює ризик втрати даних, у той час як вартість запису повної контрольної точки на диск (до 1 ТБ) кожні 500 раундів буде дуже високою, навпаки, створення нових контрольних точок включає 3 основних етапи:
Копіювання старих контрольних точок до тимчасової папки, що називається підказкою;
Змінити підказку, щоб представити дані нової контрольної точки;
Перейменуйте підказку в новий каталог контрольної точки (щоб атомарно створити нову контрольну точку).
Перший крок може бути найдорожчим, оскільки чим більший стан, тим більше часу потрібно для копіювання файлів, отже, контрольні файли стають більшими.
Однак саме тут проявляється роль контрольних точок і формату файлів дерев з журналом та об'єднанням, за допомогою LSMT цей крок є маловартісним і не розширюється зі збільшенням розміру стану, тоді як до перепроектування шару зберігання LSMT цей крок був повільним і непередбачуваним.
Структура даних з журналом та об'єднанням
Дерево з журналом та об'єднанням (LSMT) - це широко використовувана структура даних, особливо підходяща для баз даних, в Інтернет-комп'ютері вони використовуються як основа для частини зберігання PageMaps, одним із спеціальних питань, які вони можуть вирішити, є спрощення кроку "копіювання" в життєвому циклі контрольних точок, оскільки всі файли записуються лише один раз і ніколи не модифікуються.
Використовуючи LSMT, змініть (логічний) стан, записуючи додаткові файли перевизначення, щоб прочитати значення сторінки, алгоритм спочатку перевіряє нещодавно записані файли перевизначення, щоб дізнатися, чи є ця сторінка в них, якщо так, то читає значення сторінки з цього файлу, якщо ні, перевіряє наступний старіший файл перевизначення, у реалізації, що використовується в Інтернет-комп'ютері, якщо сторінка не існує в жодному з файлів перевизначення, вона читається як нуль.
На малюнку нижче показано набір з трьох файлів перевизначення, які представляють стан контейнерів, вертикальні стрілки показують різні зчитування даних та файли, з яких дані в кінцевому підсумку зчитуються.
Життєвий цикл контрольних точок LSMT виглядає наступним чином:
Перемістіть всі файли з попередньої контрольної точки до тимчасової папки, що називається підказкою;
Записати новий файл перевизначення, що містить всі зміни з моменту останньої контрольної точки;
Перейменуйте підказку в новий каталог контрольної точки (для атомарності).
Ключовим моментом є те, що кожен файл перевизначення записується лише один раз і ніколи не модифікується, тож безпечно встановлювати кілька контрольних точок на диску та обмінюватися деякими файлами між ними за допомогою жорстких посилань, зверніть увагу, що якщо життєвий цикл контрольних точок намагається змінити будь-які файли, то цей самий процес не спрацює, якщо файл має кілька жорстких посилань, зміна будь-якого з них змінить дані у всіх жорстких посиланнях, що спотворить раніше сертифіковану контрольну точку.
Структура даних з журналом та об'єднанням може зберігати кілька версій одного й того ж діапазону даних, що призводить до витрат на зберігання, які визначаються як співвідношення розміру всіх перевизначень до логічного розміру даних, які вони представляють, крім того, дані можуть бути розподілені між кількома файлами.
Зі збільшенням витрат на зберігання або кількості файлів перевизначення реалізація шару зберігання організовуватиме об'єднання, об'єднання здійснюється шляхом отримання набору перевизначень і заміни їх на єдиний файл, що містить лише останню версію кожного елемента даних, об'єднання організовується для PageMap з особливо високими витратами на зберігання або кількістю файлів і виконується у фоновому режимі, щоб не заважати виконанню повідомлень контейнера.
Дизайн, що раніше використовував Reflinks
Початковий шар зберігання Інтернет-комп'ютера не покладався на LSMT, з моменту створення Інтернет-комп'ютера в 2021 році до 2024 року шар зберігання серйозно покладався на повторне з'єднання.
Повторне з'єднання, іноді також називається копіюванням при запису, є файловою системною операцією для копіювання файлів, деякі файлові системи підтримують цю операцію, копії Інтернет-комп'ютера використовують файлову систему XFS, яка підтримує цю операцію, повторне з'єднання відрізняється від звичайного копіювання файлів тим, що воно не копіює весь вміст файлу, натомість файловій системі запам'ятовується, які дані спільні між оригінальним файлом і новим файлом, повторне з'єднання також відрізняється від жорстких посилань тим, що обидва файли можуть бути змінені незалежно один від одного.
У старому дизайні шару зберігання життєвий цикл контрольних точок працював наступним чином:
Повторно з'єднайте всі файли з попередньої контрольної точки до тимчасової папки, що називається підказкою;
Змініть файли в підказці відповідно до всіх змін з моменту останньої контрольної точки;
Перейменуйте підказку в новий каталог контрольної точки.
Однією з потенційних переваг є те, що PageMap буде представлений єдиним файлом на контрольній точці, що дозволить уникнути витрат на зберігання, але для зміни файлів під нову висоту контрольних точок потрібно повторно з'єднати відповідні файли з попередньої контрольної точки, а не жорстке з'єднання.
Переваги LSMT порівняно з Reflinks
В принципі, повторне з'єднання гарантує швидкість жорстких посилань і доступність копій, на жаль, з ростом потреб Інтернет-комп'ютера в даних (незалежно від пропускної здатності введення/виведення чи загального обсягу даних), з різних причин повторне з'єднання стало вузьким місцем у продуктивності.
1. Повільна швидкість повторного з'єднання: час, необхідний для повторного з'єднання файлів, може суттєво варіюватися, в деяких випадках може знадобитися лише кілька секунд, але в експериментах ми також спостерігали, що повторне з'єднання 370 ГБ може тривати до 10 годин, у старій логіці контрольних точок Інтернет-комп'ютера 10-годинний крок повторного з'єднання призводив до зупинки всієї підмережі на 10 годин.
Фрагментація призводить до поганої швидкості повторного з'єднання, всередині XFS файлової системи підтримується структура даних, яка відображає різні частини файлу на фактичні блоки даних на диску, коли вартість обходу цих структур даних стає високою, виникає фрагментація та повільна швидкість повторного з'єднання.
Фрагментація особливо може бути спровокована наступними послідовностями: велика кількість записів у файл, потім повторне з'єднання, велика кількість записів в одну з копій, знову повторне з'єднання тощо, на жаль, враховуючи робочий процес контрольних точок в Інтернет-комп'ютері, велике використання контейнерів викликає таку поведінку.
З іншого боку, жорсткі посилання мають стабільну продуктивність і не підлягають впливу будь-яких проблем з фрагментацією.
Перед впровадженням структури даних з журналом та об'єднанням було реалізовано багато заходів, включаючи ручну дефрагментацію файлів (через зчитування файлів і записування їх назад) і запис файлів у більші безперервні частини, обидва ці методи були пов'язані з великим збільшенням запису і все ще могли призвести до затримок до 30 хвилин.
2. Максимальний розмір стану: крім дуже довгого часу повторного з'єднання через надмірну фрагментацію, навіть при середньому рівні фрагментації час повторного з'єднання буде пропорційний загальному обсягу даних, збережених у підмережі, у попередніх реалізаціях шару зберігання Інтернет-комп'ютер встановлював ліміт зберігання для кожної підмережі до 700 ГБ, це число у значній мірі залежить від того, скільки середньої фрагментації можна повторно з'єднати за 20-30 секунд.
При використанні жорстких посилань час контрольної точки не розширюється однаково зі збільшенням обсягу даних, що усуває це вузьке місце.
3. Погана продуктивність багатопоточності: одна з цілей логіки контрольних точок - уникати синхронних операцій настільки, наскільки це можливо, оскільки під час контрольних точок виконання контейнера зупиняється, природно, потрібно врахувати, чи можна виконати повторне з'єднання у фоновому режимі, поки виконання триває (навіть якщо це дуже повільно), на жаль, досвід показує, що неможливо одночасно повторно з'єднати та зчитати файли, тому повторне з'єднання, що виконується паралельно з виконанням, лише сповільнить його.
У новому дизайні шару зберігання жорсткі посилання виконуються паралельно, і вони не сповільнюють один одного.
4. Кеш: Як зазначалося вище, зчитування даних з пам'яті контейнера відбувається одночасно з читанням даних з RAM і з контрольних файлів, повторне зчитування одного й того ж файлу, як правило, не призводить до необхідності багаторазового зчитування даних з реального жорсткого диска чи SSD, навпаки, ці дані кешуються операційною системою, на жаль, повторне з'єднання заважає кешу, оскільки спочатку повторне з'єднання файлу, а потім зчитування з нової копії не використовує кеш, тому в Інтернет-комп'ютері після запису контрольних точок спостерігається значна (і повільна) піковість зчитування з дисків, оскільки всі зчитування переключаються на нові файли, крім того, явні обчислення (тобто обчислення хешів усіх контрольних файлів для досягнення консенсусу) також отримують значну вигоду від кращого кешу.
Навпаки, при жорсткому зв'язуванні всі кеші зберігаються, будь-які нещодавно зчитані або записані дані, навіть якщо вони відбувалися в межах попередніх контрольних точок, все ще будуть кешовані, тому їх можна швидко отримати.
Результати
Шар зберігання LSMT був розгорнутий на всіх підмережах Інтернет-комп'ютера протягом кількох тижнів другого кварталу 2024 року, нижче показано показники коду копій до та після оновлення, де червона вертикальна лінія позначає час активації шару зберігання LSMT.
Перший малюнок показує час контрольної точки підмережі w4rem, ця підмережа хостить контейнери для інтеграції Bitcoin, порівняно з багатьма іншими підмережами, контейнери, що хостяться підмережею Bitcoin, мають робочі навантаження, що вимагають значних записів, тому фрагментація є особливо тривожним питанням для цієї підмережі.
З точки зору показників час контрольної точки скоротився з понад 20 секунд до всього лише 1-2 секунд, що в основному стало можливим через усунення кроку повторного з'єднання, який займав більшу частину часу в 20 секунд.
Для користувачів контейнерів Bitcoin перевага полягає в більш швидкому реагуванні: під час контрольної точки підмережа не обробляє жодних викликів оновлення або запитів копій, якщо користувач надсилає виклик оновлення або запит копії контейнеру Bitcoin на початку контрольної точки, потрібно принаймні 20 секунд, щоб отримати відповідь, використання шару зберігання LSMT практично може усунути такі неконсистентні часи відповіді.
Другий малюнок показує відсоток виконання на підмережі k44fs, відсоток виконання або швидкість блоків - це кількість блоків, які підмережа генерує за секунду.
Інтернет-комп'ютер обмежує кількість інструкцій, що виконуються за раунд, приблизно відповідно до значення, яке відповідає обсягу роботи, яку він може виконати за одну секунду, щоб остаточний відсоток виконання залишався на рівні понад 1 блок за секунду.
Перед переходом на шар зберігання LSMT процент виконання регулярно знижувався, що повністю відповідало контрольній точці, контрольна точка впливала на відсоток виконання з двох основних причин: по-перше, це час, необхідний для створення контрольної точки, під час якого не виконується жоден блок, після оновлення вплив у цьому відношенні зменшується, оскільки час контрольної точки зазвичай набагато коротший.
Друга причина полягає в тому, що поведінка кешу шару зберігання LSMT краща, зокрема, крок повторного з'єднання в реалізації старого шару зберігання призвів до втрати кешу, тому після контрольної точки будь-який контейнер, що зчитує з його пам'яті, призведе до того, що копії отримають ці дані з диска, що буде повільніше на кілька порядків, ніж ті ж самі дані, доступні у кеші в RAM, новий шар зберігання LSMT не має цієї проблеми.
Як показують показники, після оновлення падіння відсотка виконання стало значно меншим, оскільки контрольні точки самі по собі стали швидшими, більше не потрібно повторно з'єднувати, а кеш файлів також більше не втрачається.
Для користувачів контейнерів у цій підмережі це означає швидший час відповіді та вищу пропускну здатність.
Висновок
Перепроектування шару зберігання Інтернет-комп'ютера навколо структур даних з журналом та об'єднанням є важливою інвестицією в розширюваність платформи та продуктивність, воно не тільки робить можливими деякі ресурсоємні робочі навантаження, але й дозволяє Інтернет-комп'ютеру надавати контейнерам більший стан.
У контексті штучного інтелекту та запуску великих мовних моделей на ланцюзі контейнери, що обробляють великі дані, є особливо цікавими, оскільки ці контейнери залежать не лише від зберігання великих обсягів даних, але й від пропускної здатності введення/виведення.
Крім того, це закладає основу для подальших поліпшень, таких як зменшення навантаження на критичний шлях за рахунок кращого використання паралелізму, що робить Інтернет-комп'ютер швидшим у відповідях, досвід оригінального шару зберігання показує, що уникнення повторного з'єднання є критично важливим для досягнення цього, а структура даних LSMT може це зробити.
Вам сподобалася ця стаття? Поділіться своїми думками на каналі DFINITY Developers X, приєднуйтесь до нашої подорожі Stellarator частина 2 завтра, разом з Luc Bläser обговоримо покращену ортогональну постійність.
Вміст IC, який вас цікавить
Технологічні досягнення | Інформація про проект | Глобальні події
Зберігайте та підписуйте канал IC Binance
Будьте в курсі останніх новин
