Съвременна инфраструктура: проблеми и перспективи

В края на май ние сме проведе онлайн среща по темата „Модерна инфраструктура и контейнери: проблеми и перспективи“. Говорихме за контейнери, Kubernetes и принципна оркестрация, критерии за избор на инфраструктура и много други. Участниците споделиха случаи от собствената си практика.

Участниците:

• Евгений Потапов, главен изпълнителен директор на ITSumma. Повече от половината клиенти или вече се местят, или искат да преминат към Kubernetes.
• Дмитрий Столяров, технически директор "Флант". Има 10+ години опит в работата с контейнерни системи.
• Денис Ремчуков (известен още като Ерик Олдман), главен оперативен директор argotech.io, бивш RAO UES. Той обеща да говори за случаите в „кървавото“ начинание.
• Андрей Федоровски, технически директор „News360.com“След закупуването на компанията от друг играч, той отговаря за редица ML и AI проекти и инфраструктура.
• Иван Круглов, системен инженер, ex-Booking.com.Същият човек, който направи много с Kubernetes със собствените си ръце.

Теми:

• Прозрения на участниците относно контейнерите и оркестрацията (Docker, Kubernetes и др.); какво е изпробвано на практика или анализирано.
• Казус: Компанията изгражда план за развитие на инфраструктурата от години. Как се взема решението дали да се изгради (или да се мигрира текущата) инфраструктура към контейнери и Kuber или не?
• Проблеми в света на облака, какво липсва, нека си представим какво ще се случи утре.

Получи се интересна дискусия, мненията на участниците бяха толкова различни и предизвикаха толкова много коментари, че искам да ги споделя с вас. Яжте тричасово видео, а по-долу е резюме на дискусията.

Kubernetes вече е стандартен или страхотен маркетинг?

„Стигнахме до него (Kubernetes. - Ред.), когато още никой не знаеше за него. Идвахме при него дори когато го нямаше. Искахме го преди" - Дмитрий Столяров

Снимка от Reddit.com

Преди 5-10 години имаше огромен брой инструменти и нямаше единен стандарт. На всеки шест месеца се появява нов продукт или дори повече от един. Първо Vagrant, след това Salt, Chef, Puppet,... „и възстановявате инфраструктурата си на всеки шест месеца. Имате петима администратори, които са постоянно заети с пренаписване на конфигурации“, спомня си Андрей Федоровски. Той вярва, че Docker и Kubernetes са „изместили“ останалите. Docker се превърна в стандарт през последните пет години, Kubernetes през последните две години. И е добре за индустрията.

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

Kubernetes не е само оркестрация на контейнери, това е система за управление на конфигурацията с разработен API, мрежов компонент, L3 балансиране и Ingress контролери, което го прави сравнително лесно за управление на ресурси, мащабиране и абстрахиране от по-ниските слоеве на инфраструктурата.

За съжаление, в нашия живот трябва да плащаме за всичко. И този данък е голям, особено ако говорим за прехода към Kubernetes на компания с развита инфраструктура, както смята Иван Круглов. Можеше свободно да работи както в компания с традиционна инфраструктура, така и с Кубер. Основното нещо е да разберете характеристиките на компанията и пазара. Но, например, за Евгений Потапов, който би обобщил Kubernetes до всеки инструмент за оркестриране на контейнери, такъв въпрос не възниква.

Евгений направи аналогия със ситуацията през 1990-те години, когато обектно-ориентираното програмиране се появи като начин за програмиране на сложни приложения. По това време дебатът продължи и се появиха нови инструменти за поддръжка на ООП. Тогава микроуслугите се появиха като начин за отдалечаване от монолитната концепция. Това от своя страна доведе до появата на контейнери и инструменти за управление на контейнери. „Мисля, че скоро ще дойдем до време, когато няма да има въпрос дали си струва да напишем малко приложение за микросервизи, то ще бъде написано като микросервиз по подразбиране“, смята той. По същия начин Docker и Kubernetes в крайна сметка ще се превърнат в стандартно решение без нужда от избор.

Проблемът с базите данни без гражданство

Снимка от Twitter: @jankolario в Unsplash

В днешно време има много рецепти за стартиране на бази данни в Kubernetes. Дори как да отделим частта, която работи с I/O диска, от условно приложната част на базата данни. Възможно ли е в бъдеще базите данни да се променят толкова много, че да се доставят в кутия, където една част да се дирижира чрез Docker и Kubernetes, а в друга част от инфраструктурата, чрез отделен софтуер, да се осигурява частта за съхранение ? Ще се променят ли базите като продукт?

Това описание е подобно на управлението на опашка, но изискванията за надеждност и синхронизация на информацията в традиционните бази данни са много по-високи, смята Андрей. Коефициентът на попадение в кеша в нормалните бази данни остава 99%. Ако даден работник падне, стартира се нов и кешът „загрява“ от нулата. Докато кешът не се загрее, работникът работи бавно, което означава, че не може да бъде зареден с потребителско натоварване. Докато няма потребителско натоварване, кешът не се загрява. Това е порочен кръг.

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

Участниците в срещата бяха разделени на два лагера.

Денис и Андрей твърдят, че всичко, което се записва на диск - бази данни и така нататък - е невъзможно да се направи в настоящата екосистема Kuber. Невъзможно е да се поддържа целостта и последователността на производствените данни в Kubernetes. Това е фундаментална характеристика. Решение: хибридна инфраструктура.

Дори модерни облачни бази данни като MongoDB и Cassandra или опашки от съобщения като Kafka или RabbitMQ изискват постоянни хранилища на данни извън Kubernetes.

Евгений възразява: „Базите в Кубера са почти руско или почти корпоративно увреждане, което се свързва с факта, че в Русия няма Cloud Adoption.“ Малките или средни компании на Запад са Cloud. Базите данни на Amazon RDS са по-лесни за използване, отколкото сами да бърникате с Kubernetes. В Русия те използват Kuber „on-premise“ и прехвърлят бази към него, когато се опитват да се отърват от зоологическата градина.

Дмитрий също не е съгласен с твърдението, че в Kubernetes не могат да се съхраняват бази данни: „Има разлика между базите данни. И ако прокарате гигантска релационна база данни, тогава при никакви обстоятелства. Ако бутнете нещо малко и облачно родно, което е психически подготвено за полуефимерен живот, всичко ще бъде наред. Дмитрий също спомена, че инструментите за управление на бази данни не са готови нито за Docker, нито за Kuber, така че възникват големи трудности.

Иван от своя страна е сигурен, че дори ако се абстрахираме от концепциите за състояние и без състояние, екосистемата от корпоративни решения в Kubernetes все още не е готова. С Kuber е трудно да се поддържат законови и регулаторни изисквания. Например, невъзможно е да се направи решение за предоставяне на идентичност, където се изискват строги гаранции за идентификация на сървъра, чак до хардуера, който е вмъкнат в сървърите. Тази област се развива, но все още няма решение.
Участниците не успяха да постигнат съгласие, така че в тази част няма да се правят заключения. Нека дадем няколко практически примера.

Казус 1. Киберсигурност на „мегарегулатор“ с бази извън Kubera

В случай на развита система за киберсигурност, използването на контейнери и оркестрация прави възможно борбата срещу атаки и прониквания. Например, в един мегарегулатор Денис и неговият екип внедриха комбинация от оркестратор с обучена SIEM услуга, която анализира регистрационни файлове в реално време и определя процеса на атака, хакване или повреда. В случай на атака, опит за поставяне на нещо или в случай на инвазия на ransomware вирус, той чрез оркестратора прибира контейнери с приложения по-бързо, отколкото те се заразяват, или по-бързо, отколкото атакуващият ги атакува.

Случай 2. Частична миграция на бази данни на Booking.com към Kubernetes

В Booking.com основната база данни е MySQL с асинхронна репликация - има master и цяла йерархия от slave. По времето, когато Иван напуска компанията, стартира проект за прехвърляне на роби, които могат да бъдат „застреляни“ с определени щети.

В допълнение към основната база има инсталация на Касандра със самостоятелно написана оркестрация, която е написана още преди Kuber да влезе в мейнстрийма. Няма проблеми в това отношение, но е постоянен на локалните SSD. Отдалеченото съхранение, дори в рамките на същия център за данни, не се използва поради проблема с високата латентност.

Третият клас бази данни е услугата за търсене на Booking.com, където всеки възел на услугата е база данни. Опитите за прехвърляне на услугата за търсене на Kuber се провалиха, тъй като всеки възел е 60-80 GB локално хранилище, което е трудно да се „вдигне“ и „загрее“.

В резултат на това търсачката не беше прехвърлена в Kubernetes и Иван не смята, че ще има нови опити в близко бъдеще. Базата данни MySQL беше прехвърлена наполовина: само роби, които не се страхуват да бъдат „застреляни“. Касандра се е настанила перфектно.

Изборът на инфраструктура като задача без общо решение

Снимка от Мануел Гайсингер от Pexels

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

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

Иван: „Определено бих започнал компания в облака сега, просто защото е по-бързо“, макар и не непременно по-евтино. С развитието на рисковия капитализъм стартъпите нямат големи проблеми с парите, а основната задача е да завладеят пазара.

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

Данъкът при всички случаи ще трябва да се плати и Иван ще плати този, който му позволява да плаща по-малко в бъдеще. "Защото просто поради факта, че се возя във влак, който другите движат, ще пътувам много по-далеч, отколкото ако седна на друг влак, в който трябва сам да налея гориво.“, казва Иван. Когато компанията е нова и изискванията за латентност са десетки милисекунди, тогава Иван би погледнал към „операторите“, в които днес са „опаковани“ класическите бази данни. Те повдигат верига за репликация, която се превключва в случай на отказ и т.н.

За малка компания с няколко сървъра Kubera няма смисъл“, казва Андрей. Но ако планира да нарасне до стотици сървъри или повече, тогава се нуждае от автоматизация и система за управление на ресурсите. 90% от случаите си заслужават разходите. Освен това, независимо от нивото на натоварване и ресурси. Има смисъл за всички, от стартиращи фирми до големи компании с милионна аудитория, постепенно да се ориентират към продукти за оркестриране на контейнери. „Да, това наистина е бъдещето“, убеден е Андрей.

Денис очерта два основни критерия - мащабируемост и стабилност на работа. Той ще избере инструментите, които са най-подходящи за задачата. „Може да е noname, сглобен на колене, и върху него има Nutanix Community Edition. Това може да бъде втори ред под формата на приложение на Kuber с база данни в бекенда, която се репликира и има определени RTO и RPO параметри" (цели за време/точка за възстановяване - прибл).

Евгений установи възможен проблем с персонала. В момента на пазара няма много висококвалифицирани специалисти, които да разбират „глътката“. Наистина, ако избраната технология е стара, тогава е трудно да наемете някой друг освен хора на средна възраст, които са отегчени и уморени от живота. Въпреки че други участници смятат, че това е въпрос на подготовка на кадри.
Ако поставим въпроса за избор: да стартираме малка компания в публичния облак с бази данни в Amazon RDS или „на място“ с бази данни в Kubernetes, тогава въпреки някои недостатъци, Amazon RDS стана изборът на участниците.

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

Оценка на използването на Kubernetes

Слушателят Антон Жбанков зададе капан въпрос на апологетите на Kubernetes: как избрахте и проведохте проучване за осъществимост? Защо Kubernetes, защо не виртуални машини например?

Снимка от Татяна Еремина в Unsplash

Дмитрий и Иван му отговориха. И в двата случая чрез проба и грешка беше взета поредица от решения, в резултат на които и двамата участници пристигнаха в Kubernetes. Сега фирмите започват самостоятелно да разработват софтуер, който има смисъл да се прехвърля към Kuber. Не говорим за класически системи на трети страни, като 1C. Kubernetes помага, когато разработчиците трябва бързо да направят издания, с непрекъснато непрекъснато подобрение.

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

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

Какво ни очаква

Снимка от Дрю Биймър на Unsplash

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

Мислите ли, че ще дойде време, когато ще има инструмент като Ubuntu за света на Linux? Може би един инструмент за контейнеризиране и оркестрация ще включва Kuber. Това ще улесни изграждането на локални облаци.

Отговорът беше даден от Иван: „В момента Google изгражда Anthos – това е тяхната пакетна оферта, която разгръща облака и включва Kuber, Service Mesh, мониторинг – целият хардуер, който е необходим за локални микроуслуги.“ Почти сме в бъдещето."

Денис също спомена Nutanix и VMWare с продукта vRealize Suite, който може да се справи с подобна задача без контейнеризация.

Дмитрий сподели мнението си, че намаляването на „болката“ и намаляването на данъците са две области, в които можем да очакваме подобрения.

За да обобщим дискусията, подчертаваме следните проблеми на съвременната инфраструктура:

• Трима участници незабавно идентифицираха проблем със състоянието.
• Различни проблеми с поддръжката на сигурността, включително възможността Docker да се окаже с множество версии на Python, сървъри за приложения и компоненти.
  Преразход, който е добре да се обсъди на отделна среща.
  Предизвикателство за учене, тъй като оркестрацията е сложна екосистема.
  Често срещан проблем в индустрията е неправилното използване на инструменти.

  Останалите изводи зависят от вас. Все още има усещането, че не е лесно комбинацията Docker+Kubernetes да стане „централна“ част от системата. Например операционните системи се инсталират първо на хардуера, което не може да се каже за контейнерите и оркестрацията. Може би в бъдеще операционните системи и контейнерите ще се слеят със софтуера за управление на облак.

  
  Снимка от Габриел Сантос Фотография от Pexels

  Използвам възможността да поздравя майка ми и да ви напомня, че имаме група във Фейсбук "Управление и развитие на големи ИТ проекти", канал @feedmeto с интересни публикации от различни технологични блогове. И моят канал @rybakalexey, където говоря за управление на развитието в продуктови компании.

Източник: www.habr.com