Знает ли бизнес полностью, на что тратит деньги? Неоднократно советовал некоторым бизнесменам посидеть инкогнито на собеседованиях и посмотреть на происходящее. Потому что ни бизнес, ни содтрудники бывают ни разу не довольны результатами найма (когда нанимают мастера спорта по прохождению собесов). Пусть бизнес добьётся развёрнутого ответа причины отказа на этапе первичного рассмотрения резюме. Почему бы ему не узнать, чем рукводствуется рекрутер, когда принимает то или иное решение? Потому что отсутствиев резюме фотографии, ФИО, телефонного номера, указанного возраста (реальные кейсы отказов), недостаточный по их меркам опыт (надо не менее 6 лет, а у кандидата всего лишь 5) или наоборот слишком большой опыт (вероятность, что сразу откажут, даже больше чем при недостатке опыта) не должны служить причиной отказа. Но поскольку со слов рекрутеров, сорсеров, талент менеджеров и HR у них всего лишь меньше минуты на рассмотрение резюме и жуткий KPI, то на выходе именно такой результат. А они ни в чём не виноваты.
Могу привести пример из собственного опыта поиска работы. Резюме сделано с учётом требований современных реалий: где надо подробно расписано, где лучше не надо -лаконично указано. Откликаюсь с этим резюме в один известный бигтех и получаю отказ в тот же день. Но почему-то моё резюме зацепило аутстафф-компанию, с которым общался задолго до отклика в бигтех. В ходе общения высняется , что как раз подхожу под требуемую позицию в тот самый бигтех. Прохожу все многочисленные этапы и дохожу до проверки СБ (то есть всё серьёзно с их стороны). Пока СБ как положено тянут резину, получаю предложение от другой аутстафф-компании в другой отечественный бигтех, куда пробовал несколько раз силы пробиться через первичный отсев разными вариантами резюме. Не удивлюсь, что возможно будет похожая ситуация и с другой аутстафф-компанией, когда предложат позицию в бигтехе, где сразу до этого завернули на первичном этапе.
Для ответа на этот вопрос (почему свои костыли вместо промышленного стандарта?) нужно окунуться в исторический экскурс. Когда-то ВБ построили свои ЦОД, о чём они постоянно рассказывали в своё время на собеседованиях, чтобы произвести впечатление масштабом на кандидата. Помогали им в этом выходцы из Mail.ru, которые в основном и были носителями технологий. Как раз эти носители, опираясь на свой опыт и навыки с предыдущего места работы, убеждали (но не доказывали), что сервер легко может перемалывать огромные нагрузки по работе с файловой системой работая на soft RAID массиве, а всякие дисковые полки и прочие специализированные решения от лукавого и дорого. Не знаю как сейчас, но в свою пору эти иженеры хвалились, что будут на этом всём (soft RAID) пилить огромную кластерную ФС и как бы сейчас не описывалось то, что не совсем смогло нормально работать на кластерной ФС. Потому что все эти экзерсисы с динамической сетевой маршрутизацией, дроблением на шарды, последующим циклическим распределением по VOL из далека напоминает примитивную кластерную ФС, только без особых гарантий целостности и непротиворечивости данных.
Что касается метрик в статье, к ним надо относиться с определённой долей скепсиса. Например, приведённые значения от запроса до получения картинки каталога товара, которые якобы обычно составляют 8–14 мс в мобильном приложении ВБ (а у вас чуть ли не поголовно сидят с мобильного приложения) это ближе к области фантастики. Даже когда клиент находится в городе, где есть их точка присутствия (HyperLook-точки с двухуровневым кешем - в терминах ВБ), картинке из ЦОД-а предстоит сделать много hop-ов, прежде чем попасть в сеть мобильного оператора и ещё поскакать там.
Не совсем с первых строк понятно о чём речь. Потому что статья называется "Файловое хранилище Wildberries: бескомпромиссный HighLoad", а потом автор представляется как "CTO продукта CDN". А нестыковка случилась именно в том что CDN (Content Delivery Network) это история про географически распределённую сетевую инфраструктуру, обеспечивающую быструю доставку контента пользователям и единственное что там может быть связанное с хранением данных на дисках это кеши. Только речь в первом абзаце упорно идёт о хранилище и мне в пору думаться начинает, что ВБ взяли и запилили распределённое хранилище данных прямо на точках присутствия (HyperLook-точки с двухуровневым кешем - в терминах ВБ). От такой догадки становится жутко и интересно, но читаю дальше.
Дохожу до момента, где автором постулируется: "Скорость получения изображения — ключевой компонент клиентского опыта.", вспоминаю Амазон с его требованиями к отзывчивости сайта у клиентов и понимаю, что что-то знакомое описывает автор. После слов "Клиентское приложение или веб-сайт запрашивает картинку товара на домен CDN MediaBasket, и запрос сразу попадает на конкретную шарду хранилища" сразу становится всё понятно. В том же самом Амазон (только в их облаке) это старый добрый сервис CloudFront. Очень удобный сервис: прикрутил к S3-бакету, который вроде может быть под 50 ТБ и не переживаешь за доступность статики. Довольно часто приходилось пользоваться, потому что тоже надо было отдавать много статического контента и как можно быстрей. Плюс бонусом сам сервис отдавал неплохую статистику по клиентам и отданному контенту (уже в предковидную эпоху наблюдался явный перекос в сторону мобильных пользователей). Дальше стало не так животрепещаще, как думал изначально и начались технические вопросы, может в чём-то показаться даже придирки.
Чтобы обеспечивать минимальные задержки, архитектура доставки должна быть предельно простой.
Наверное корректнее было сказать, с минимальным числом посредников -- дистанция доставки предельно короткой. Можно сказать, что здесь во весь рост встаёт физика, когда из-за большого числа промежуточных звеньев итоговая скорость падает по причине задержек на каждом узле. Вам может быть показаться даже смешным, но мне так и не получилось донести до фронтендеров мысль брать картинки прямо из хранилища, а не дёргать по этому поводу бэкенд, где по пути ещё был самодельный WAF со своими причудами (между прочим дело происходило тоже на маркетплейсе, но отличающемся своей спецификой). Про умельцев, хранящих всю статику в базе данных (MySQL) отдельная тема разговора (между прочим on-line игра).
Далее мы используем BGP и Round Robin для размазывания нагрузки на чтение по репликам. На каждой реплике поднят BIRD, демон динамической маршрутизации, — он анонсирует адрес в нашей сети.
BGP взяли от ваших сетевиков? Рассматривали ли OSPF? Если да, то можете ли поделиться впечатлениями и результатами сравнения?
Если одна из реплик перестаёт отвечать (например, из-за отказа диска), мы быстро гасим её BGP-анонс
Делается это автоматически (readness probe, liveness probe,...), либо имеется автоматизированное (то бишь с участием человека) решение?
Мы сознательно выбрали физические серверы вместо виртуальных машин, чтобы выжать максимум производительности
Это понятно. Виртуалки -- это про изоляцию ресурсов, а у вас обыкновенная целиком ваша хранилка для статики. Вопрос в другом: профилируете ли вы операционные системы после инсталляции на сервера специальным образом для выжимания максимальной производительности? Сейчас на ум приходят настройки планировщиков ОС для работы с дисками и сетевым стеком, специфические настройки дисковой и сетевой подсистемы в sysctl.conf. Может быть какие-то свои решения для повышения performance, например, вы заказываете определённые модели серверов, которые сполна покрывают ваши хотелки по скорости отдачи данных? Может быть у вас свой кастомный ориентированный под даннный профиль нагрузки дистрибутив?
Btrfs, ZFS и другие ФС не рассматриваем по причине их неготовности к проду.
На счёт Btrfs ещё могут быть разночтения, если вам нужен RAID6 или даже RAID60. Что-то вроде там не чисто, уже не помню. Но насколько помню ZFS была готова к проду ещё в ту пору, когда Ext4 не было в природе.
Главное — результат, а не догма.
Это как раз не догма. Особенно, когда появляется фактор времени. Когда нужен только результат (сегодня) во главе без закладывания мер и подходов по развитию и расширению, по прошествии времени может случиться, что вы упрётесь в технический долг или прилетит Чёрный лебедь.
Наша R&D-команда проектирует следующее поколение хранилища — на жёстких дисках с расширенной ёмкостью без потери производительности (> млн RPS). Это новый экспериментальный проект. Идея в том, что HDD дают существенно больше места, но с ними трудно делать гибко-масштабируемое хранилище.
Да и они просто дешевле эти HDD)) И плюс дефицит SSD на фоне массовых закупок в ДЦ для ИИ.
Основная проблема мотор-колеса в описанном сценарии это ресурс и сложность сборки.
Ну для кого-то это явные плюсы. Кроме этого туда добавляется проблема охлаждения двигателя, непонятное поведение при отказе одного либо нескольких двигателей по тем или иным причинам, возможны ещё какие-то неявные на первый момент проблемы.
По этому очень сомнительно что производители начнут использовать мотор-колесо.
Скорее всего так и будет. Электрички внедрялись на волне эко хайпа и гос поддержки. Интерес пройдёт, поддержка государства прекратится, и дальше интересно будет посмотреть на судьбу продаж электричек.
иллюстрация того, что есть термины, которые загажены. Неймспейс - такой термин. Используют по делу или не по делу.
Прекрасно понимаю, что это такой термин. Только зачем приплетать значение термина namespace в контексте кластера кубернетес к значению механизма ядра операционной системы? Зачем путать?
скачивается из docker registry. Ну, что за вопросы, в конце-концов? Какая разница откуда.
Другими словами, когда я запущу в изолированном сетевом контуре ванильный кластер k8s, для корректной работы сетевого адресного пространства кластера мне загодя надо будет положить этот образ контейнера, откуда он будет подтянут? Так? Ещё раз обращу внимание: изолированный (Air Gap) от интернета кластер k8s развёртывается, настраивается такой же изолированный regestry, и чтобы всё заработало, мне кроме CNI надо ещё будет заранее позаботится о контейнере pause? Ну и вообще иногда есть большая разница откуда и что скачивается. Особенно когда речь заходит об образах контейнеров кластера k8s. Есть такое правило (обычно его упоминают в контексте финансов): то что ты не контроллируешь, тебе не принадлежит. Думаю, это вообще будет неплохой темой для обуждения в ТГ канале.
Если контейнеры приложения (дополнительные к pause) перестартуют - были бы приключения с переназначением IP адресов на контейнер.
В чём проблема? Под случайно, либо намерено убили, k8s его поднял, все живы и довольны с новым адресом. Переехал под с одной ноды на другую (особенно это касается переезда statfullset приложения), адрес поменялся, внутренний сервер имён отработал (если успевает). Какие проблемы?
Но если совсем коротко - в винде не контейнеры, а полноценные виртуальные машины, которые пытаются продать как контейнеры.
В MacOS аналогичная ситуация с контейнерами Docker.
У виртуалки ОЧЕВИДНО есть айпи адрес всегда (минимум один).
Запуская простенький Docker контейнер в нативной среде исполнения (ОС Linux), у него тоже будет свой ip адрес. Можно постараться и запустить без адреса, но и с виртуалками такой номер можно будет провернуть тоже. Поэтому это далеко не всегда очевидно. Например, запуск виртуалки с каким-нибудь злоредом для изучения на первых порах лучше делать с отключенной сетью, то бишь без ip вообще. Потому уже запускаешь с сетевым интерфейсом, к которому прикручен wireshark, и смотришь куда и как этот шифровальщик или троян пытается лезть.
Все плюсы мотор-колеса перекрываются парой здоровенных минусов
Таки ви покупаете, или таки продаёте? Если шо, таки тут целый забор плюсов, которые таки пахнут здоровенным гешевтом))
Если устроиться на диване поудобнее, повспоминать эволюцию автопрома за последние 20 - 30 лет, то в результате такой ретроспективы мы увидем, что после определённого периода, производители под надуманными предлогами (экологическая повестка и т. п.) перешли на практически одноразовые модели с туманными возможностями ремонта, некоторые даже с подписной моделью на тот или иной функционал.
Пока не понятна судьба описываемого решения, но с точки зрения очередного витка эволюции авторома (больше напоминающего пике) это очень заманчивый и даже перспективный шаг. Потому что кроме самого привода к нему нужны провода, которые скорее всего станут таким же расходником как и сам двигатель, а это отдельная статья доходов (обязательно на автофоруме найдётся гений, который с пеной у рта будет доказывать, что лучше всего и правильнее ездить на проводах из вакуумированной меди, которые предварительно прогревали специальным током в течении нескольких дней), само собой старые колёсные диски будут несовместимы (очередной источник гешевта), так же возможны свои особенности тормозной системы и соответственно целое поле для возможных решений (можно придумать "совместимость" и многие купятся).
Тут вопрос не только во вменяемой массе, а в том, что при повреждении колеса мы меняем и мотор.
Ну это просто очередная золотая жила для произодителей авто и сервисных центров)) Тем более что его на заводе легко сделать неразборным впринципе (догадайтесь почему?), потому что крайне важный узел ну и Хайтек.
Это сильно дороже
Как раз с точки зрения экономики производителя это как раз очень и очень хорошо)) Немного поработать маркетологам и вуа-ля все пересели на современный, удобный, сверхманёвренныи и экономичный, (здесь ещё ряд прилагательных превосходной степени)
Мотор проще прикрыть от грязи и воды в раме, чем в колесе
Вы так слона не продадите)) Если их ставить в каждое калесо и они так же будут ходить как резина на колёсах или чуть меньше, в итоге превратятся в расходники, так это как раз то что нужно массовому автопрому. Если ещё до зимних и летних (как типы сезонных покрышек) вариантов дойдёт, то уже лет через пять старые электрички будут запрещены законодательно под надуманными причинами)))
Очень странно, что китайцы ещё не оседлали эту технологию)
Сейчас расскажу зачем так, кроме того что в некоторых компаниях (тупо использовать логин и пароль) так принято))
Допустим у вас есть хост, выступающий в роли бастиона к некоторому защищаемому ресурсу. Оговорю сразу, что в плане безпасности сервер бастиона наворочен, начиная с настроенного аудита системных вызовов, политик SELinux, дополнительных настроек в systemctl и избыточного логирования всего происходящего на сервере. С самого сервера Бастион можно выполнять строго определённые действия (например, подключение к базе данных поверх SSH). Ничего сложного нет нагенерить ключи и потом открытый ключ класть на сервере бастиона, а приватный отправлять пользователю. Как раз на последнем моменте начинается интересное знакомство с компьютерной грамотностью коллег и человеческим фактором)) Некоторые коллеги прекрасно знают, куда в их ОС нужно положить приватный ключ, как его беречь и для чего он вообще нужен. У других "лапки" и свои особенности расположений ключей в зависимости от ОС (Linux, Windows, MacOS ), и тут может случиться веселье с длительными объяснениями что, куда и зачем. Так же остаётся открытый вопрос защиты доступа к этим ключам. Другими словами, во весь рост всплывает проблема под названием человеческий фактор. Поэтому приходится идти на такие упрощения в доступе, чтобы предоставить доступ и не околеть при этом: - почтой отправляется методичка по тому, как запустить на рабочей машине SSH в зависимости от ОС, инструкция по настройке подключения в зависимости от приложения (например, для pgAdmin и DBeaver) и логин пользователя; - в корпоративном мессенжере отправляется пароль.
Согласен, ключи - это хорошо и удобно (особенно на элиптических кривых хороши), пока не встаёт во весь рост куча проблем с их распространением в массовых количествах и обновлением. Кроме этого при настроенном взаимодействии сервера Бастион с внутрикорпоративной системой поставки авторизации (IdP) упрощается процесс администрирования доступами. Ну и далеко не все IdP поддерживают хранение ключей на своей стороне.
Откуда он берётся этот образ контейнера? Собирается вместе с основным образом контейнера рабочего приложения, или откуда-то подкладывается/скачивается?
ну, вот так, айпишник пода же где-то должен висеть, когда пересоздаются его контейнеры.
Возвращаясь к первоначальному вопросу (Не совсем понятно как запущенный контейнер с названием pause держит сетевой неймспейс ядра линукса? Что его держать?) не совсем понятно зачем контейнеру (pause) держать механизм ядра операционной системы namespace? Подвожу к тому, что на самом деле намешано в кучу механизм ядра операционной системы (namespace) и механизм выдачи адресов подам в Kubernetes. Потому что возникает логиный вопрос: как это реализовано в Windows, где в ядре отсутствует механизм namespase?
Здесь оно идет вероятно в противопоставлении к namespace кубернетеса, которые логические сущности
Непонятно к чему вообще нужно противопостовлять механизм ядра операционной системы и механизм логического разделения ресурсов в проложении?
Ну это вроде очевидно из самого названия "размерность". Другими словами, это говорит, что данная физическая величина находится в своей системе измерений: метры в своей, килограммы в своей, секунды в своей.
В системе SI определено семь основных размерностей (физических величин), остальные являются производными и вроде как их достаточно для описания любых свойств физических объектов и явлений.
Странно другое. Куда смотрит трудовая инспекция, что такие вакансии местами с явным нарушением трудового законодательства появляются? Их это не касается? Их хата с краю? Зачем тогда вообще нужна эта структура? Тем более что трудовые споры между сотрудником и работодателем обычно решаются в суде и трудовая инспекция вообще никак не участвует в этом.
Каждый под имеет один скрытый контейнер, который всегда присутствует и запущен на базе образа с названием pause. Задача этого контейнера — держать сетевой неймспейс ядра линукса
Возникает логичный вопрос на базе какого именно образа запускается этот контейнер? Не совсем понятно как запущенный контейнер с названием pause держит сетевой неймспейс ядра линукса? Что его держать?
Как правило, IP-адрес пода назначается из специальной сети, которая называется clusterNetwork
Может быть придераюсь к словам и определениям, только сетевое адресное пространство подов однозначно ограничено clusterNetwork.
Для сети подов обычно используют так называемый overlay. По сути это некая дополнительная сеть, которая существует только в рамках узлов кластера.
В народе (у сетевиков) это просто оверлейная сеть. И это совсем не некая дополнительная, а вполне определённая сеть)), которая работает поверх текущей (поэтому зовётся overlay-ной).
Есть существенное отличие между адресами подов и адресами сервисов. Первые всё-таки маршрутизируются внутри кластера и физически присутствуют на интерфейсах узла, где запущен под. Адреса же сервисов обычно не присутствуют на интерфейсах и существуют только внутри iptables цепочек на узлах. При помощи iptables трафик, попадающий на такой «виртуальный» адрес, преобразуется и отправляется на те поды, на которые указывает сервис.
1 Сетевые адресные пространства подов кластера и сервисов кластера не пересекаются - то бишь разные. 2 Адреса подов и адреса сервисов маршрутизируются только и только внутри кластера кубернетес иначе было бы странно, и физически они нигде не присутствуют - они виртуальные. Физические адреса (суть аппаратные IP адресса) очень редко где светятся)) 3 Сами сервисы реализованы в виде правил iptables природа их (виртуальная) аналогичная природе подов.
Третья подсеть — это сама сеть рабочих узлов кластеров
Не-е-е)) Это самая что ни на есть первая. И от неё надо начинать плясать.
Компонент kube-proxy отвечает за реализацию Services через iptables или IPVS. Но это не самый эффективный способ. Современные CNI, такие как Calico и Cilium, могут полностью заменить kube-proxy, реализуя его функциональность напрямую (часто через eBPF). Это убирает лишний компонент и делает обработку трафика еще быстрее.
Можно сравнивать между собой сетевые пакетные фильтры iptables и eBPF по их возможностям, главное отличие в том что старый добрый iptables работает в user space, eBPF в kernel space операционной системы. Это значит, что за счёт отсутствия переключения контекста производительность eBPF будет быстрее. Но безопасники могут на корню зарубить эту затею с eBPF)))
В Альфа-Банке был один из самых интересных собесов на позицию DevOps-инженера (всего технических было пару десятков)Как сказал собеседующий инженер: мне "повезло", ведь они тестят новый формат техсобесов - блиц Интенсивный собес с кучей адекватных технических вопросов с максимально быстрыми ответами
Жертвы ЕГЭ не иначе. Даже не знаю почему собеседующий так радуется. Опыт показывает, когда человек правильно отвечает на вопросы, это совершенно не значит, что он понимает, о том что говорит (привет ИИ). Тем более, что сейчас многие "наблатыкались" правильно отвечать, но не более.
Минус один: нельзя пообсуждать какие то вопросы, это мешает в полной мере раскрыться самому и раскрыть собеседующих как инженеров
Здесь ещё второй минус - нельзя задавать вопросы собеседующему. Это могут быть уточняющие, могут быть встречные, могут быть вопросы для обдумывания. У меня ещё советское техническое образование и нас учили, даже требовали, задавать вопросы, задаваться вопросами.
Оффер был на руках уже через неделю, с последующим моим (по глупости) отказом))
Не стоит совершенно об этом жалеть. Высокая ЗП (кто сказал, что высокая?) не всегда оправдывает условия и устои.
Что касается автора статьи, по памяти работы в Т1, приходится ещё их доучивать или переучивать. Там такие шедевры иногда получались, на знаменитом сайте для этих вещей нужна отдельная рубрика.
Ну самое главное для понимания: Для чего нужен DevOps-инженер? Перво наперво это сборка и доставка кода (то самое CI / CD). Всё остальное вторично, третично, либо вообще не имеет никакого отношения DevOps. Кстати, как раз на эту тему есть довольно хорошая статья про DevOpsи его основные показатели.
Спасибо за интересную и познавательную статью. Можете прокомментировать тему прямого преобразования ионизирующего излучения в электрический ток? Есть ли подвижки и действующие решения?
В наших палестинах аббревиатура ИБ в сути своей часто расшифровывается как имитационная безопасность. Обычно там много бюрократии, присутствует своя артистократия и труднообъяснимые внутренние процессы выработки и принятия решений.
Написание жалобы во многие надзорные органы часто выглядит труднопроходимым квестом. Видимо изначально так было задумано. Как и последующее перенаправление в долгий ящик всех этих жалких обращений от людишек.
Гальваническая развязка нужна для других целей и они не связаны с ИБ. Потому что трансформатор обратимое устройство и ему by design всё равно в какую сторону трансформировать электрическую энергию: первичная и вторичная обмотки так называются только для удобства восприятия. Поэтому, чтобы избежать прелести с передачей данных по электрической сети надо применять схему двойного преобразования: переменка -> постоянка -> переменка
Знает ли бизнес полностью, на что тратит деньги? Неоднократно советовал некоторым бизнесменам посидеть инкогнито на собеседованиях и посмотреть на происходящее. Потому что ни бизнес, ни содтрудники бывают ни разу не довольны результатами найма (когда нанимают мастера спорта по прохождению собесов). Пусть бизнес добьётся развёрнутого ответа причины отказа на этапе первичного рассмотрения резюме. Почему бы ему не узнать, чем рукводствуется рекрутер, когда принимает то или иное решение? Потому что отсутствиев резюме фотографии, ФИО, телефонного номера, указанного возраста (реальные кейсы отказов), недостаточный по их меркам опыт (надо не менее 6 лет, а у кандидата всего лишь 5) или наоборот слишком большой опыт (вероятность, что сразу откажут, даже больше чем при недостатке опыта) не должны служить причиной отказа. Но поскольку со слов рекрутеров, сорсеров, талент менеджеров и HR у них всего лишь меньше минуты на рассмотрение резюме и жуткий KPI, то на выходе именно такой результат. А они ни в чём не виноваты.
Могу привести пример из собственного опыта поиска работы. Резюме сделано с учётом требований современных реалий: где надо подробно расписано, где лучше не надо -лаконично указано. Откликаюсь с этим резюме в один известный бигтех и получаю отказ в тот же день. Но почему-то моё резюме зацепило аутстафф-компанию, с которым общался задолго до отклика в бигтех. В ходе общения высняется , что как раз подхожу под требуемую позицию в тот самый бигтех. Прохожу все многочисленные этапы и дохожу до проверки СБ (то есть всё серьёзно с их стороны). Пока СБ как положено тянут резину, получаю предложение от другой аутстафф-компании в другой отечественный бигтех, куда пробовал несколько раз силы пробиться через первичный отсев разными вариантами резюме. Не удивлюсь, что возможно будет похожая ситуация и с другой аутстафф-компанией, когда предложат позицию в бигтехе, где сразу до этого завернули на первичном этапе.
Если нас интересует только добавление картинок, смысл задумываться об удалении? (иронично)
Можно ничего не удалять, а перезатирать новыми данными - как вариант
Для ответа на этот вопрос (почему свои костыли вместо промышленного стандарта?) нужно окунуться в исторический экскурс. Когда-то ВБ построили свои ЦОД, о чём они постоянно рассказывали в своё время на собеседованиях, чтобы произвести впечатление масштабом на кандидата. Помогали им в этом выходцы из Mail.ru, которые в основном и были носителями технологий. Как раз эти носители, опираясь на свой опыт и навыки с предыдущего места работы, убеждали (но не доказывали), что сервер легко может перемалывать огромные нагрузки по работе с файловой системой работая на soft RAID массиве, а всякие дисковые полки и прочие специализированные решения от лукавого и дорого. Не знаю как сейчас, но в свою пору эти иженеры хвалились, что будут на этом всём (soft RAID) пилить огромную кластерную ФС и как бы сейчас не описывалось то, что не совсем смогло нормально работать на кластерной ФС. Потому что все эти экзерсисы с динамической сетевой маршрутизацией, дроблением на шарды, последующим циклическим распределением по VOL из далека напоминает примитивную кластерную ФС, только без особых гарантий целостности и непротиворечивости данных.
Что касается метрик в статье, к ним надо относиться с определённой долей скепсиса. Например, приведённые значения от запроса до получения картинки каталога товара, которые якобы обычно составляют 8–14 мс в мобильном приложении ВБ (а у вас чуть ли не поголовно сидят с мобильного приложения) это ближе к области фантастики. Даже когда клиент находится в городе, где есть их точка присутствия (HyperLook-точки с двухуровневым кешем - в терминах ВБ), картинке из ЦОД-а предстоит сделать много hop-ов, прежде чем попасть в сеть мобильного оператора и ещё поскакать там.
Не совсем с первых строк понятно о чём речь. Потому что статья называется "Файловое хранилище Wildberries: бескомпромиссный HighLoad", а потом автор представляется как "CTO продукта CDN". А нестыковка случилась именно в том что CDN (Content Delivery Network) это история про географически распределённую сетевую инфраструктуру, обеспечивающую быструю доставку контента пользователям и единственное что там может быть связанное с хранением данных на дисках это кеши. Только речь в первом абзаце упорно идёт о хранилище и мне в пору думаться начинает, что ВБ взяли и запилили распределённое хранилище данных прямо на точках присутствия (HyperLook-точки с двухуровневым кешем - в терминах ВБ). От такой догадки становится жутко и интересно, но читаю дальше.
Дохожу до момента, где автором постулируется: "Скорость получения изображения — ключевой компонент клиентского опыта.", вспоминаю Амазон с его требованиями к отзывчивости сайта у клиентов и понимаю, что что-то знакомое описывает автор. После слов "Клиентское приложение или веб-сайт запрашивает картинку товара на домен CDN MediaBasket, и запрос сразу попадает на конкретную шарду хранилища" сразу становится всё понятно. В том же самом Амазон (только в их облаке) это старый добрый сервис CloudFront. Очень удобный сервис: прикрутил к S3-бакету, который вроде может быть под 50 ТБ и не переживаешь за доступность статики. Довольно часто приходилось пользоваться, потому что тоже надо было отдавать много статического контента и как можно быстрей. Плюс бонусом сам сервис отдавал неплохую статистику по клиентам и отданному контенту (уже в предковидную эпоху наблюдался явный перекос в сторону мобильных пользователей).
Дальше стало не так животрепещаще, как думал изначально и начались технические вопросы, может в чём-то показаться даже придирки.
Наверное корректнее было сказать, с минимальным числом посредников -- дистанция доставки предельно короткой. Можно сказать, что здесь во весь рост встаёт физика, когда из-за большого числа промежуточных звеньев итоговая скорость падает по причине задержек на каждом узле. Вам может быть показаться даже смешным, но мне так и не получилось донести до фронтендеров мысль брать картинки прямо из хранилища, а не дёргать по этому поводу бэкенд, где по пути ещё был самодельный WAF со своими причудами (между прочим дело происходило тоже на маркетплейсе, но отличающемся своей спецификой). Про умельцев, хранящих всю статику в базе данных (MySQL) отдельная тема разговора (между прочим on-line игра).
BGP взяли от ваших сетевиков? Рассматривали ли OSPF? Если да, то можете ли поделиться впечатлениями и результатами сравнения?
Делается это автоматически (readness probe, liveness probe,...), либо имеется автоматизированное (то бишь с участием человека) решение?
Это понятно. Виртуалки -- это про изоляцию ресурсов, а у вас обыкновенная целиком ваша хранилка для статики. Вопрос в другом: профилируете ли вы операционные системы после инсталляции на сервера специальным образом для выжимания максимальной производительности? Сейчас на ум приходят настройки планировщиков ОС для работы с дисками и сетевым стеком, специфические настройки дисковой и сетевой подсистемы в sysctl.conf. Может быть какие-то свои решения для повышения performance, например, вы заказываете определённые модели серверов, которые сполна покрывают ваши хотелки по скорости отдачи данных? Может быть у вас свой кастомный ориентированный под даннный профиль нагрузки дистрибутив?
На счёт Btrfs ещё могут быть разночтения, если вам нужен RAID6 или даже RAID60. Что-то вроде там не чисто, уже не помню. Но насколько помню ZFS была готова к проду ещё в ту пору, когда Ext4 не было в природе.
Это как раз не догма. Особенно, когда появляется фактор времени. Когда нужен только результат (сегодня) во главе без закладывания мер и подходов по развитию и расширению, по прошествии времени может случиться, что вы упрётесь в технический долг или прилетит Чёрный лебедь.
Да и они просто дешевле эти HDD)) И плюс дефицит SSD на фоне массовых закупок в ДЦ для ИИ.
Ну для кого-то это явные плюсы. Кроме этого туда добавляется проблема охлаждения двигателя, непонятное поведение при отказе одного либо нескольких двигателей по тем или иным причинам, возможны ещё какие-то неявные на первый момент проблемы.
Скорее всего так и будет. Электрички внедрялись на волне эко хайпа и гос поддержки. Интерес пройдёт, поддержка государства прекратится, и дальше интересно будет посмотреть на судьбу продаж электричек.
Прекрасно понимаю, что это такой термин. Только зачем приплетать значение термина namespace в контексте кластера кубернетес к значению механизма ядра операционной системы? Зачем путать?
Другими словами, когда я запущу в изолированном сетевом контуре ванильный кластер k8s, для корректной работы сетевого адресного пространства кластера мне загодя надо будет положить этот образ контейнера, откуда он будет подтянут? Так?
Ещё раз обращу внимание: изолированный (Air Gap) от интернета кластер k8s развёртывается, настраивается такой же изолированный regestry, и чтобы всё заработало, мне кроме CNI надо ещё будет заранее позаботится о контейнере pause?
Ну и вообще иногда есть большая разница откуда и что скачивается. Особенно когда речь заходит об образах контейнеров кластера k8s.
Есть такое правило (обычно его упоминают в контексте финансов): то что ты не контроллируешь, тебе не принадлежит. Думаю, это вообще будет неплохой темой для обуждения в ТГ канале.
В чём проблема? Под случайно, либо намерено убили, k8s его поднял, все живы и довольны с новым адресом. Переехал под с одной ноды на другую (особенно это касается переезда statfullset приложения), адрес поменялся, внутренний сервер имён отработал (если успевает). Какие проблемы?
В MacOS аналогичная ситуация с контейнерами Docker.
Запуская простенький Docker контейнер в нативной среде исполнения (ОС Linux), у него тоже будет свой ip адрес. Можно постараться и запустить без адреса, но и с виртуалками такой номер можно будет провернуть тоже. Поэтому это далеко не всегда очевидно. Например, запуск виртуалки с каким-нибудь злоредом для изучения на первых порах лучше делать с отключенной сетью, то бишь без ip вообще. Потому уже запускаешь с сетевым интерфейсом, к которому прикручен wireshark, и смотришь куда и как этот шифровальщик или троян пытается лезть.
Таки ви покупаете, или таки продаёте? Если шо, таки тут целый забор плюсов, которые таки пахнут здоровенным гешевтом))
Если устроиться на диване поудобнее, повспоминать эволюцию автопрома за последние 20 - 30 лет, то в результате такой ретроспективы мы увидем, что после определённого периода, производители под надуманными предлогами (экологическая повестка и т. п.) перешли на практически одноразовые модели с туманными возможностями ремонта, некоторые даже с подписной моделью на тот или иной функционал.
Пока не понятна судьба описываемого решения, но с точки зрения очередного витка эволюции авторома (больше напоминающего пике) это очень заманчивый и даже перспективный шаг. Потому что кроме самого привода к нему нужны провода, которые скорее всего станут таким же расходником как и сам двигатель, а это отдельная статья доходов (обязательно на автофоруме найдётся гений, который с пеной у рта будет доказывать, что лучше всего и правильнее ездить на проводах из вакуумированной меди, которые предварительно прогревали специальным током в течении нескольких дней), само собой старые колёсные диски будут несовместимы (очередной источник гешевта), так же возможны свои особенности тормозной системы и соответственно целое поле для возможных решений (можно придумать "совместимость" и многие купятся).
Ну это просто очередная золотая жила для произодителей авто и сервисных центров)) Тем более что его на заводе легко сделать неразборным впринципе (догадайтесь почему?), потому что крайне важный узел ну и Хайтек.
Как раз с точки зрения экономики производителя это как раз очень и очень хорошо)) Немного поработать маркетологам и вуа-ля все пересели на современный, удобный, сверхманёвренныи и экономичный, (здесь ещё ряд прилагательных превосходной степени)
Вы так слона не продадите)) Если их ставить в каждое калесо и они так же будут ходить как резина на колёсах или чуть меньше, в итоге превратятся в расходники, так это как раз то что нужно массовому автопрому. Если ещё до зимних и летних (как типы сезонных покрышек) вариантов дойдёт, то уже лет через пять старые электрички будут запрещены законодательно под надуманными причинами)))
Очень странно, что китайцы ещё не оседлали эту технологию)
Сейчас расскажу зачем так, кроме того что в некоторых компаниях (тупо использовать логин и пароль) так принято))
Допустим у вас есть хост, выступающий в роли бастиона к некоторому защищаемому ресурсу. Оговорю сразу, что в плане безпасности сервер бастиона наворочен, начиная с настроенного аудита системных вызовов, политик SELinux, дополнительных настроек в systemctl и избыточного логирования всего происходящего на сервере. С самого сервера Бастион можно выполнять строго определённые действия (например, подключение к базе данных поверх SSH).
Ничего сложного нет нагенерить ключи и потом открытый ключ класть на сервере бастиона, а приватный отправлять пользователю. Как раз на последнем моменте начинается интересное знакомство с компьютерной грамотностью коллег и человеческим фактором))
Некоторые коллеги прекрасно знают, куда в их ОС нужно положить приватный ключ, как его беречь и для чего он вообще нужен. У других "лапки" и свои особенности расположений ключей в зависимости от ОС (Linux, Windows, MacOS ), и тут может случиться веселье с длительными объяснениями что, куда и зачем. Так же остаётся открытый вопрос защиты доступа к этим ключам. Другими словами, во весь рост всплывает проблема под названием человеческий фактор. Поэтому приходится идти на такие упрощения в доступе, чтобы предоставить доступ и не околеть при этом:
- почтой отправляется методичка по тому, как запустить на рабочей машине SSH в зависимости от ОС, инструкция по настройке подключения в зависимости от приложения (например, для pgAdmin и DBeaver) и логин пользователя;
- в корпоративном мессенжере отправляется пароль.
Согласен, ключи - это хорошо и удобно (особенно на элиптических кривых хороши), пока не встаёт во весь рост куча проблем с их распространением в массовых количествах и обновлением.
Кроме этого при настроенном взаимодействии сервера Бастион с внутрикорпоративной системой поставки авторизации (IdP) упрощается процесс администрирования доступами. Ну и далеко не все IdP поддерживают хранение ключей на своей стороне.
Откуда он берётся этот образ контейнера? Собирается вместе с основным образом контейнера рабочего приложения, или откуда-то подкладывается/скачивается?
Возвращаясь к первоначальному вопросу (Не совсем понятно как запущенный контейнер с названием pause держит сетевой неймспейс ядра линукса? Что его держать?) не совсем понятно зачем контейнеру (pause) держать механизм ядра операционной системы namespace? Подвожу к тому, что на самом деле намешано в кучу механизм ядра операционной системы (namespace) и механизм выдачи адресов подам в Kubernetes. Потому что возникает логиный вопрос: как это реализовано в Windows, где в ядре отсутствует механизм namespase?
Непонятно к чему вообще нужно противопостовлять механизм ядра операционной системы и механизм логического разделения ресурсов в проложении?
Ну это вроде очевидно из самого названия "размерность". Другими словами, это говорит, что данная физическая величина находится в своей системе измерений: метры в своей, килограммы в своей, секунды в своей.
В системе SI определено семь основных размерностей (физических величин), остальные являются производными и вроде как их достаточно для описания любых свойств физических объектов и явлений.
Странно другое. Куда смотрит трудовая инспекция, что такие вакансии местами с явным нарушением трудового законодательства появляются? Их это не касается? Их хата с краю? Зачем тогда вообще нужна эта структура? Тем более что трудовые споры между сотрудником и работодателем обычно решаются в суде и трудовая инспекция вообще никак не участвует в этом.
Возникает логичный вопрос на базе какого именно образа запускается этот контейнер? Не совсем понятно как запущенный контейнер с названием pause держит сетевой неймспейс ядра линукса? Что его держать?
Может быть придераюсь к словам и определениям, только сетевое адресное пространство подов однозначно ограничено clusterNetwork.
В народе (у сетевиков) это просто оверлейная сеть. И это совсем не некая дополнительная, а вполне определённая сеть)), которая работает поверх текущей (поэтому зовётся overlay-ной).
1 Сетевые адресные пространства подов кластера и сервисов кластера не пересекаются - то бишь разные.
2 Адреса подов и адреса сервисов маршрутизируются только и только внутри кластера кубернетес иначе было бы странно, и физически они нигде не присутствуют - они виртуальные. Физические адреса (суть аппаратные IP адресса) очень редко где светятся))
3 Сами сервисы реализованы в виде правил iptables природа их (виртуальная) аналогичная природе подов.
Не-е-е)) Это самая что ни на есть первая. И от неё надо начинать плясать.
Можно сравнивать между собой сетевые пакетные фильтры iptables и eBPF по их возможностям, главное отличие в том что старый добрый iptables работает в user space, eBPF в kernel space операционной системы. Это значит, что за счёт отсутствия переключения контекста производительность eBPF будет быстрее. Но безопасники могут на корню зарубить эту затею с eBPF)))
Есть. Но пока не у нас. По сути переизобрели и по новому подошли к электрохимическому полированию.
Спасибо вам за хорошую и самое главное полезную статью. Многие вещи стали ясны и понятны
Жертвы ЕГЭ не иначе. Даже не знаю почему собеседующий так радуется. Опыт показывает, когда человек правильно отвечает на вопросы, это совершенно не значит, что он понимает, о том что говорит (привет ИИ). Тем более, что сейчас многие "наблатыкались" правильно отвечать, но не более.
Здесь ещё второй минус - нельзя задавать вопросы собеседующему. Это могут быть уточняющие, могут быть встречные, могут быть вопросы для обдумывания. У меня ещё советское техническое образование и нас учили, даже требовали, задавать вопросы, задаваться вопросами.
Не стоит совершенно об этом жалеть. Высокая ЗП (кто сказал, что высокая?) не всегда оправдывает условия и устои.
Что касается автора статьи, по памяти работы в Т1, приходится ещё их доучивать или переучивать. Там такие шедевры иногда получались, на знаменитом сайте для этих вещей нужна отдельная рубрика.
Ну самое главное для понимания: Для чего нужен DevOps-инженер? Перво наперво это сборка и доставка кода (то самое CI / CD). Всё остальное вторично, третично, либо вообще не имеет никакого отношения DevOps. Кстати, как раз на эту тему есть довольно хорошая статья про DevOps и его основные показатели.
Спасибо за интересную и познавательную статью. Можете прокомментировать тему прямого преобразования ионизирующего излучения в электрический ток? Есть ли подвижки и действующие решения?
В наших палестинах аббревиатура ИБ в сути своей часто расшифровывается как имитационная безопасность. Обычно там много бюрократии, присутствует своя артистократия и труднообъяснимые внутренние процессы выработки и принятия решений.
Написание жалобы во многие надзорные органы часто выглядит труднопроходимым квестом. Видимо изначально так было задумано. Как и последующее перенаправление в долгий ящик всех этих жалких обращений от людишек.
Гальваническая развязка нужна для других целей и они не связаны с ИБ. Потому что трансформатор обратимое устройство и ему by design всё равно в какую сторону трансформировать электрическую энергию: первичная и вторичная обмотки так называются только для удобства восприятия.
Поэтому, чтобы избежать прелести с передачей данных по электрической сети надо применять схему двойного преобразования:
переменка -> постоянка -> переменка
По сути напоминает импульсный источник питания.