Добре работеща мрежа се състои от добре работещи възли, устройства, които правят това, което се изисква от тях, както се очаква, в рамките на приет диапазон на производителност. Работата на Старейшините е да се уверят, че Възрастните в тяхната секция са работещи и да предприемат действия чрез гласуване, ако забележат нещо нередно. Проследяването на неработещи добре възли е голяма част от това, върху което екипът работи в момента.
Общ напредък
Тази седмица разбрахме, че потенциално губим възли по време на голям преместване и разделяне, като възелът мисли че се е присъединил, но с последващо разделяне валидният ключ на Секцията се е преместил напред. Възелът, мислейки, че всичко е наред, няма да се опита да се свърже отново. Така че @anselme работи върху проверката на нашите познания за мрежата и след като ги актуализира, ще опита отново процеса на присъединяване за тези загубени възли.
Работата по DBC продължава, като първоначалните стъпки за съхранение на Разходната книга са на място.
При стартиране на тестови мрежи за отстраняване на грешки в нестабилността на данните разкрихме двойка потенциални блокирания. В единия случай видяхме четенията на DataStorage да висят по време на репликация. Така че се заехме със създаването на някои еталони за тестване на ChunkStorage и с това открихме задънена улица в основния код за съхранение.
Друго (непотвърдено) блокиране се случваше по време на процеса на почистване на PeerLink. Трудно е да се каже дали това определено се случва, но виждахме блокирани възли и нашият код за почистване беше извикван често около блокирането. Като се задълбочим, виждаме голям потенциал за опростяване, така че направихме точно това.
Още едно потенциално блокиране се появява при дисфункция, като структурата на вложените данни се чете неправилно без mut заключване. 
Трудно е да се каже дали всичко това се е случвало със сигурност (изисква се да възникнат специфични условия), но със сигурност тези промени трябва да са стъпки в правилната посока!
С всички тези поправки, най-после имаме интегриран DKG-Handover с работата по Generation (който е много по-стабилен спрямо други скорошни промени). Продължаваме да работим върху стабилността, като предстоят още тестове/бенчмаркове за DataStorage и някои други настройки на потоците за репликация на данни, които се тестват (трябва да разширим набора от възли, които искаме за данни, както при голям отлив на възли, шансовете от наказание на един прясно присъединен възел нарастват и изглежда, че започваме да губим данни!).
Проследяване на дисфункцията
Проследяването на дисфункцията е непрекъснат процес. Винаги има нови поведения за тестване и моделиране, така че това е итеративен процес, позволяващ подобрения в производителността и стабилността, докато вървим напред.
Проследяването на дисфункцията е различно от справянето със злонамереност. Злонамереността е обективно доказуемо лошо действие, като подписване на невалидно мрежово съобщение и работата на всички възли е да идентифицират такива възли и да ги накажат. Дисфункцията, от друга страна, означава „неправилно поведение“ и задължение на Старейшините е да разберат какво означава това.
Възелът може да не работи поради фактори от околната среда, като временно забавяне на местния интернет или условия, които се натрупват с течение на времето, като например недостатъчно място за съхранение или памет. Или дисфункцията може да е внезапна, като прекъсване на захранването или принудително рестартиране.
Дисфункцията обхваща и оперативните фактори, включително качеството и броя на съобщенията, както и съхраняването и доставянето на данни при поискване.
Някои видове дисфункция (загуба на данни, продължителна загуба на свързаност) са по-сериозни от други и затова трябва да се третират по различен начин.
Можем да тестваме производителността на възел спрямо други възли в секцията, но какво ще стане, ако цялата секция е под стандарта в сравнение с други секции? Какво тогава?
Както можете да разберете, проследяването на дисфункцията е сложен проблем с много променливи.
Цели на проследяването на дисфункцията
Като наблюдаваме възлите, докато изпълняват задълженията си, ние искаме да премахнем всички проблеми в зародиш, преди да се разрастнат. Премахването на възел трябва да бъде последна мярка, вместо това искаме да предприемем действия - или да накараме собственикът на възела, фермерът, да предприеме действия - за да коригираме проблема.
Този процес на постепенно коригиране на поведението на възела трябва да бъде автоматизиран и гъвкав, да може да реагира на променящите се условия, а не да се основава на произволни твърдо кодирани параметри.
Проследяването на дисфункция е свързано с оптимизиране, но не е само оптимизиране за производителност - това би довело до централизация. Домашните потребители не биха могли да се конкурират със сървъри в центрове за данни - те винаги биха били относително нефункционални.
До къде сме
В момента имаме опростена версия на дисфункцията.
Тестовете за жизненост проверяват дали възлите са онлайн, което позволява на Старейшините да предприемат действия, ако не са. Това е разширено, за да санкционира възлите не само за загубата на съхранени парчета данни, но и за прекратяване на връзки и изоставане по отношение на познанията за мрежата.
Тестването на жизнеността, след като е настроено, за да се гарантира, че не сме твърде груби (както бяхме досега) или твърде меки към неправилно работещи възли, е добра първа стъпка за осигуряване на стабилна мрежа, но с проследяването на дисфункция искаме да отидем по-далеч и да изградим модел, който оптимизира и за други фактори.
Наказването на възли понастоящем означава отпадането им, но скоро ще включва други мерки като намаляване наполовина на възрастта на възлите. Решенията относно начина на действие, което ще се предприема ще бъде вземано от Старейшините чрез консенсус.
Както споменахме, известна степен на „дисфункционално поведение“ е неизбежна и в момента експериментираме с класифицирането на възлите като добри (95%+ коефициент на успеваемост за дадена операция), посредствени (75%) или лоши (30%), така че да може да третираме всеки клас по различен начин в зависимост от неговата сериозност, без твърдо кодиране на каквито и да било „очаквани“ стойности (PR #1179). Също така искаме да знаем колко възли от всеки клас има вдадена Секция.
Хранилището „sn_dysfunction“ е тук.
Къде отиваме
Искаме да разширим броя на тестовете, които правим, и параметрите, които проверяваме, за да сме сигурни, че моделираме мрежата по смислен начин.
Идеите включват редовно допитване до Възрастните, за да им се даде малко работа за доказване, което също може да провери дали държат актуална версия на някои променящи се данни. Променящите се данни са CRDT и в крайна сметка ще се сближат, но периодичната свързаност може да означава, че една реплика връща остаряла версия. Колко остаряла е тя, би имало отношение към оценката за дисфункция, кумулативен брой, даден на всеки възел. Ако това надхвърли праговата стойност, този възел може да бъде прекласифициран като „посредствен“ или „лош“ и да бъде третиран по съответния начин. През какъв период от време продължаваме да добавяме към резултата предстои да тестваме.
Не всички проблеми могат да бъдат проследени чрез сравняване на производителността между възлите (ако всички възли са лоши, това означава лоша секция; ако твърде много секции са лоши, това означава лоша мрежа), така че ще разгледаме подходящи глобални параметри.
Също така трябва да обмислим как можем да използваме проследяване на дисфункцията, за да насърчим разнообразието от възли и да избегнем централизацията, така че както възел върху AWS, така и Raspberry Pi да могат да имат своята роля в мрежата.
Също така искаме да разгледаме как представяме информацията за дисфункцията на крайния потребител, фермера, вероятно като набор от параметри по подразбиране, които могат да се настройват чрез конфигурационен файл, а по-късно и чрез GUI.
В крайна сметка Safe е като глобален компютър, Старейшините са като многонишков процесор, а Възрастните са като гигантски твърд диск. Искаме този твърд диск да се самовъзстановява и процесорът да може да се адаптира към промените.
Всичко това ни отвежда в сферата на chaos engineering, който се използва от такива като Netflix и Google на техните облачни платформи, за да се гарантира, че отделните откази на сървърите им не свалят цялата система.
Вероятно има нещо, което можем да научим и тук, докато работим, за да направим Safe мрежата стабилна и надеждна.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България