Гол метал срещу облак: проучване

Горещо обсъжданата тема за голия метал срещу облака наскоро излезе начело в общността на EOS. Както при повечето неща в света на криптовалутите / блокчейн, и около дискусията има огромно количество шум и FUD (страх, несигурност и съмнение). Тук съм, за да ви кажа, че голият метал срещу облака е неоснователен аргумент и всички са твърде заети, за да изострят вилата си, за да се съсредоточат върху това, което наистина има значение.

Преди да се потопим, нека направим крачка назад и си припомним какво е важно; на това, с което се съгласяват производителите на блок, когато подписват договора за регистрация на Block Producer: надеждното, сигурно и честно функциониране на EOS mainnet.

Само за запис, ние от EOS Дъблин сме в Bare-Metal Brigade ™ и с тази статия добавихме специална значка, която можете да изтеглите за вашия сайт или Twitter. Можете да изтеглите значката си тук.

Нека започнем с някои дефиниции, тъй като терминологията е всичко и тук може да има някои нови термини.

Чист метал

По самото си определение, голият метал просто означава физически сървър с един наемател. С други думи, тя трябва да работи много подобно на домашния ви компютър. Инсталирате MacOS или Windows на вашия лаптоп / десктоп и той взаимодейства директно с хардуера (поне за тази тема).

Системата работи на хард метал, а не на софтуерна абстракция (виртуализация) на този хардуер.

облак

Когато хората говорят за облак, те обикновено се отнасят към инфраструктура като платформа за услуга (IaaS), разпределена среда, състояща се от много наематели, виртуализирани сървъри. Платформи като Amazon AWS, Microsoft Azure, Google Cloud Platform (GCP) или IBM Bluemix са примери за публични облачни инфраструктури. Идеята е, че използвайки съвременни техники за виртуализация, можете да стартирате инфраструктура на високо мащабируема, разпределена мрежа от сървъри на по-ниска цена от голия метал.

Облак срещу Гол-метал

Отне ми известно време, за да разбера това безсмислено сравнение, но най-накрая разбрах, че това е просто неразбиране на терминологията, с убеждението, че голият метал = хардуер, който е собственост и се управлява направо, докато облак = нает или нает хардуер.

Това е просто невярно. Голият метал и облакът не са противоположности.

Въз основа на дефиницията по-горе е напълно възможно да стартирате голи метални сървъри в облачна среда, просто попитайте EOS Dublin. Сравняването на облак с голи метали е сходно с това да се каже нещо като „Audi срещу спортна кола.“ Сега Audi, производител на автомобили, прави широка гама от автомобили, включително спортни автомобили. Спортните автомобили са само категория продукт, който Audi предлага. Можете също така да купите спортен автомобил от други производители като Porsche, по-малка независима компания като Koenigsegg (безплатен лос с всяка покупка) или можете да изградите свой собствен.

Единичен наемател срещу мулти-наемател или Виртуализиран срещу физически

Това е истинската същност на проблема и дебатът, върху който трябва да се съсредоточим. Виртуализираните среди за много наематели имат много предимства, ако не се интересувате наистина от хардуера, който използвате или нямате нужда от гаранции за наличността на ресурсите. Като споделяте сървър с други, всеки в своята собствена градина със стени, вие също споделяте разходите.

От друга страна, ако имате шумни съседи, които обичат да изпълняват ресурсно интензивни работни натоварвания върху своя дял в сървъра, те могат много да ви повлияят, което да доведе до влошена производителност. Възможно е те също да могат да се изкачат над тунели или да се тунели под тях.

Блок-производителят трябва да гарантира, че техният възел е изолиран от действията на други участници. Това е невъзможно да се гарантира при работа на споделен хост.

Единично или многократно наемане

Единичен наемател и мулти-наемател описват типове архитектура, които определят начина, по който хардуер или софтуер се разпределят на потребителите. В архитектурата на един наемател, един клиент има достъп до софтуера / хардуера, докато при сценарий с много наематели един отделен екземпляр се споделя между няколко потребители едновременно. Това наистина се свежда до компромис между разходи и ползи.

Пример от реалния свят и такъв, при който терминологията не се нуждае от превод, би било да помислим за жилищна сграда, която е разделена на множество единици спрямо отделна къща. Ако споделяте сграда с други наематели, вие също споделяте някои ресурси, като например водата, която влиза в сградата, или канализационните услуги, които изхвърлят отпадъците. Ако живеете в сграда със слабо водно налягане и не повече от двама наематели могат да пуснат пералнята или да вземат душ едновременно, вашата способност да използвате този ресурс, водоснабдяването, може да бъде засегната от другите в сградата.

Същото важи и за системите с много наематели. Ако имате шумен съсед, който работи с всички видове интензивна обработка на данни, това би могло да намали количеството на мощността, с която разполагате. Сега можете да седнете с другите наематели в сградата и да се съгласите на график, но никой не е обвързан от това. В среда с един наемател, точно както там, където имате цялото място за себе си или семейството си, вие също контролирате много повече от разпределението на ресурсите.

виртуализация

Това е много широка тема с много приложения и далеч не е нова, датираща от 60-те. За целите на тази статия, когато говорим за виртуализация, ние говорим за хардуерна виртуализация. т.е. да се направи една хардуерна част изглежда много хардуерни части. Тази виртуализация се обработва в софтуер, при който операционна система ще изпълнява неща, наречени виртуални машини. Изглежда, че всяка виртуална машина е свой собствен компютър направо спрямо софтуера, който работи на нея. Това дава възможност на доставчик на услуги да поддържа множество клиенти (мулти-наемател) на един физически сървър.

Само съветът

Значи това е! Ако пускате гол-метал и избягвате виртуализация, вие сте най-добрият BP в света и автоматично трябва да стигнете до върха! Е, не. Сървърите, компютрите, които всъщност управляват платформата EOS, са само малка част от инфраструктурната картина. Нека проучим някои други области, които са от решаващо значение за сигурна и надеждна настройка.

Поддържаща инфраструктура

След като разполагате със своя лъскав гол-метъл сървър, трябва да имате предвид някои тривиални въпроси като захранването, работата в мрежа, физическата сигурност и достъпа до интернет. Изграждате ли сами това или използвате ли съществуващата инфраструктура? Ако използвате съществуващата инфраструктура, сигурни ли сте, че компанията може да изпълни своите обещания? Ще ги пуснат резервните генератори, когато захранването отпада? Имат ли достатъчно парични потоци, за да издържат на бури?

Готов съм да се обзаложа, че по-голямата част от настройките на голи метали работят със своя хардуер на наети стелажни пространства в център за данни. И е възможно същите тези центрове за данни да работят в облачна инфраструктура за един от големите момчета, както и някаква форма на частна облачна инфраструктура. Така че, ако всички работиха в центрове за данни на Equinix, бихме ли се почувствали по-добре, отколкото ако всички работиха на облак като Amazon AWS?

Собственост

Имаше аргументи, че работата в облачна инфраструктура е лоша, защото не притежавате хардуера и следователно той може да бъде взет от вас по всяко време.

Какво имаме предвид, когато казваме собственост? Ако е бил взет заем за закупуване на хардуера, тогава не го притежавате направо, докато не бъде извършено последното плащане. Ако имате подкрепата си от инвеститори, най-вероятно нямате напълно и всичко, и сте обект на щастие.

Само облеклата, които са се измъкнали от собствените си джобове, могат наистина да твърдят, че притежават своя хардуер и са независими. Предполагам, че това е сравнително малък брой БП, които могат да кажат това, извън по-големите размени, разбира се.

независимост

Тук има някои припокривания със собствеността, но ако мислим за независимостта да управлявате собствения си хардуер, по начина, по който искате, тогава, ако сте заключени в многогодишна сделка с център за данни, за да хоствате вашия хардуер, все още ли си независим? Много по-различно ли е да сте заключени в облачен доставчик за запазен екземпляр?

Ако стартирате хардуера си в нечий друг център за данни, рискувате да ви бъде отказан физически достъп. Да речем, че някой е извършил убийство в центъра за данни и мястото е заключено като местопрестъпление. Знам за такова възникване в офис среда и никой не можеше да получи достъп до сървърната стая в продължение на няколко дни. Естествено, ще имате вторичните си възли да работят на отделно място, но това може да означава, че сега работи без аварийна грешка, докато можете да възстановите достъпа. Това може да изглежда малко нагледно, но това е технологично: ако може да се случи, ще се случи.

Друг популярен аргумент е, че ако работите на облачна платформа, живеете в страх, че ако тези зли корпорации не се съгласят с това, което правите, те просто ще ви отрежат. Въпреки че това е напълно възможно, това е много невероятно. Бих бил по-притеснен от нещо на правителственото ниво. Наистина ли беше толкова дълго, че забравихме за многобройните актове на правителствената цензура, които отказаха достъп до услуги като Twitter? Или страхотната защитна стена на Китай? Убийства на Либия, Русия се опитва да забрани достъпа до Telegram? Независимо къде управлявате хардуера си, имате опасност да бъдете затворени, ако някой го иска достатъчно зле.

ловкост

Ако сте на гол метал, колко бързо можете да преместите физическото местоположение на вашата инфраструктура? Или да надстроите хардуера? Какво ще кажете за резервни части / замени? Да приемем, че сървърът ви се проваля зрелищно и на практика трябва да замените целия блок. Как това се вписва във вашия бюджет? И какъв е срокът за получаване на тази подмяна? Разбира се, може да имате авариен авариен преход, но докато не получите подмяната, се изпълнявате без отказ. В EOS Дъблин работим с голи метали в облака, така че ако нещо се обърка, можем просто да добавим нов екземпляр от голи метали към нашата платформа и да продължим да работим. Ако някой използва своя собствен метал в център за данни, той ще трябва физически да излезе и да закупи нов сървър, след което да го инсталира и настрои.

отзивчивост

Станахме свидетели на редица проблеми, откакто мрежата се появи на живо и повечето от тях са свързани със софтуера. Точно тази неделя (8 юли) видяхме срив на редица възли, включително в топ 21, поради проблем с конфигурацията. За протокола EOS Дъблин не беше засегнат от това и нашите възли продължиха да работят. Способността на BP да реагира на тези „спешни ситуации“ е от първостепенно значение за функционирането на мрежата. Предстои да видим повече проблеми в бъдеще; това е неизбежно, така че трябва да се уверим, че сме включили екипи, които могат да реагират бързо.

За какво отново спорим?

Да се ​​надяваме, че сега имате по-голямо разбиране, че има повече разбиране на компетентността на BP да поддържа мрежата EOS, различна от коя компания използва за стартиране на техния хардуер.

Първо, нека се съгласим да спрем да говорим за „облак срещу баре-метал“, тъй като тези двама всъщност не са противоположни начини да виждат инфраструктура. Вместо това, нека се съсредоточим върху по-доброто разбиране на начина на създаване на BP-та, за да сравним разнообразието в мрежата. Определянето на способността на BP да управлява инфраструктура трябва да се свежда до нещо повече от това дали те работят върху облачна инфраструктура, наети стелажни пространства или в собствен център за данни.

Второ, нека работим за създаването на по-структуриран подход за определяне на компетентността на БП, съсредоточен върху повече от хардуера.

заключение

Аргументът „гол-метал срещу облак“ е безсмислен. По-точното сравнение би било „виртуализирано спрямо физическо“, но това се фокусира само върху много малка част от инфраструктурната картина за БП. Когато определяме способността на кандидат за производител на блок да поддържа мрежата на EOS, трябва да разгледаме повече от само машините, които работят.

Ние от EOS Дъблин чувстваме силно, че активните възли за производство на блок трябва да работят върху голи метали за максимална производителност и сигурност. Също така смятаме, че разнообразието в общността е едно от най-силните предимства. Не можем да имаме всички, които работят в облака, както не можем да имаме всички, които да бягат от гаража си. Нуждаем се от смес. Но най-важното е, че имаме нужда от компетентни екипи. Екипи, които са ангажирани за подобряване на EOS и отговарят на възникнали проблеми.

Ние, общността на EOS, се нуждаем от по-информиран и научен подход за оценка на способността на BP да управлява и поддържа професионална настройка, независимо от мястото, където се намира хардуерът. Трябва да гарантираме, че в режим на готовност действително работи хардуерът, за който казват, че е и че са готови за действие, ако бъдат призовани. Изтъкнатият Томас Кокс работи върху такава рамка, докато говорим, което означава, че скоро трябва да имаме по-официален процес за изграждане на картина на БП и способността им да служат на общността.

Дотогава може би просто трябва да започнем да молим BP-та да публикуват разписките си?

Внимавайте за нова публикация през следващите няколко дни, като се гмурнете как сме създадени и защо, но засега бъдете сигурни, че нашите възли за производство на блок са голи метали!

Искаме да чуем от вас!

EOS Dublin On Telegram: https://t.me/eosdb

EOS Dublin Online: https://www.eosdublin.com/

EOS Дъблин В Twitter: https://twitter.com/eosdublin

EOS Dublin On Steemit: https://steemit.com/@eosdublin

EOS Dublin On Medium: https://medium.com/@eosdublin/

EOS Dublin On Meetup: https://www.meetup.com/EOS-Dublin/

EOS Dublin On Everipedia: https://everipedia.org/wiki/eos-dublin/