Интернет-компании подбирают и тестируют оборудование для дата-центров не только по номинальным характеристикам, полученным от производителя, но и с учетом реальных производственных задач, которые будут выполняться на этом оборудовании.
Затем, когда дата-центр уже спроектирован, построен и запущен, проводятся учения — узлы отключаются без ведома сервисов и видно, насколько они подготовлены к такой ситуации.
Дело в том, что при такой сложной инфраструктуре невозможно добиться полной отказоустойчивости.
В каком-то смысле идеальный дата-центр — это тот, который можно отключить, не затрагивая сервисы, например поиск Яндекса.
Руководитель группы экспертизы динамического поиска Олег Федоров был среди спикеров на большом совещании по поиску Яндекса, которое состоялось в начале августа.
Он рассказал обо всех основных аспектах проектирования дата-центров для задач, связанных с обработкой огромных объемов данных.
Под катом — стенограмма и слайды Олега.
Меня зовут Олег, я работаю в Яндексе шесть лет. Начинал я менеджером в отделе качества поиска, сейчас больше занимаюсь вопросами, связанными с работой наших крупных дата-центров — слежу за тем, чтобы наш поиск работал и т. д. Давайте попробуем умозрительно спроектировать небольшой центр обработки данных со 100 тысячами машин, который может отвечать поиском, другими сервисами и т. д. Давайте сделаем это очень просто, умозрительно, сверху.
Поиск облачных задач.
С чем мы столкнулись? Какими принципами мы руководствуемся при построении больших систем? 
Так же, как любой театр начинается с вешалки, можно попробовать начать строить дата-центр, на каком процессоре мы будем проектировать наши серверы, на каком оборудовании это все будет работать, сколько его будет и т. д. Для этого попробуем пройти три простых шага.
Мы хотим протестировать наше оборудование.
Мы хотим посчитать, во сколько нам обойдется владение таким оборудованием.
Мы хотим как-то выбрать оптимальное решение.
Картинка для привлечения внимания: 
Чтобы в ближайшее время построить свой дата-центр, выбрать интересный процессор и быть готовым через полтора года, нам необходимо заранее получить образцы техники.
Многие из вас знают это, потому что тестировали оборудование еще до того, как оно появилось на массовом рынке.
С чем мы будем тестировать? Возьмем типовые задачи для облака, которые будут работать на наших серверах чаще всего: поиск, кусок индекса, который нам показывают результаты, что-то еще.
Давайте возьмем все эти образцы и поищем аномалии.
Был яркий пример: мы взяли модель процессора от одного из производителей и время рендеринга у нас сильно снизилось.
Сюрприз.
Мы разобрались: действительно, была проблема с компилятором, но тем не менее аномалия может возникнуть.
Другой пример: производитель анонсировал новый набор инструкций SSE, мы немного переписали наш код — он стал существенно быстрее.
Это своего рода конкурентное преимущество нашей модели, все в порядке.
Давайте пойдем немного глубже.
Допустим, мы выбрали некий набор процессоров.
Вот мои любимые фотографии, которые привлекают внимание.
Мой iPhone недавно перегрелся.
Географическое положение.
Все мы знаем, что дата-центр для российской компании может быть построен в России или не в России – в разных странах, в разных климатических и географических зонах.
Например, на экваторе будет жарко, но можно использовать солнечную электроэнергию.
На севере с электричеством будет все сложнее, а вот с охлаждением все очень хорошо и т. д. Везде есть свои плюсы и минусы.
Нам обязательно нужно будет подумать о поддержании нашего дата-центра.
Доставка компонентов в холодный регион или в незнакомую страну с непредсказуемым административным ресурсом может оказаться затруднительной.
Некоторые компоненты удастся добыть лишь с большим трудом и т. д. Нам обязательно нужно просчитать остальную инфраструктуру для каждого нашего набора процессоров.
Если мы возьмем процессор, выделяющий 160 Вт тепла, нам, вероятно, придется задуматься об охлаждении, нам понадобится более мощный радиатор, более мощный сервер.
Куда движется индустрия на данный момент? Мы, как и все остальные, хотим охлаждаться наружным воздухом.
Возьмите наружный температурный воздух с улицы, пропустите его через наши серверы и получите охлаждение.
Таким образом, мы обеспечим, чтобы как можно больше энергии тратилось на наши окончательные расчеты и как можно меньше на поддерживающую инфраструктуру.
Многие знают: есть коэффициент PUE, все стремятся к нему.
Допустим, мы подсчитали, сколько стандартных операций готов выполнять процессор и примерно оценили стоимость владения.
Я специально зашифровал имена процессоров; это все какие-то умозрительные цифры.
Каков общий подход? Как правило, все выглядит так, что процессор максимальной производительности начинает немного вырваться вперед и его условная стоимость владения решением с производительностью на ядро возрастает в геометрической прогрессии.
Оптима живет где-то по пути.
Из этого правила всегда есть исключение.
Для некоторых немассивных приложений, где задержка очень критична, мы хотим получить максимальную производительность на ядро.
Или мы хотим быстро собрать, нарисовать и т. д. что-то онлайн — мы можем позволить себе взять несколько процентов исключительного оборудования.
Попробуем рассмотреть другие аспекты.
У нас очень сложное многомерное пространство: процессор, память, SSD, диски, сеть, ряд неизведанных измерений.
Мы постоянно расширяемся.
Обо всем этом вам придется подумать.
Модель сложная, многомерная, Интернет медленно меняется, меняются и наши подходы к поиску.
Все это закладываем в модель и обязательно рассчитываем.
Вторая картинка для привлечения внимания: 
Многие люди, вероятно, знают распределение космического микроволнового фонового излучения — именно так мы пытаемся компьютерно смоделировать то, как выглядит наша Вселенная.
Данные выглядят примерно так же.
Есть очень жаркие районы.
Например, все почему-то ищут сайт ВКонтакте — не знаю почему.
Или несколько котят. Эти данные очень горячие, часто используются, очень хочется разместить их в памяти где-нибудь поближе к процессору и т.д. Есть ли какие-нибудь драйвера.
Мой предыдущий ноутбук у меня уже 10 лет, и для него, для старой Ubuntu, мне нужны были драйвера.
Почему-то ни у кого, кроме меня, этой просьбы долгое время не было.
Пробовал искать по логам - никому не интересно.
Эти данные, наверное, никому не нужны — положу куда-нибудь подальше, на холодные диски с мелкой сложной репликацией и т.п.
К счастью, у нас все экспоненциально.
Самые горячие данные очень малы; вы можете попытаться достичь памяти.
А самые неинтересные и ненужные корейские спам-сайты можно положить куда-нибудь на диск и забыть о них.
Картина того, насколько сложны требования различных приложений в нашем облаке.
Попробуем немного классифицировать приложения, которые у нас есть.
Есть аналогия: купил пустой аквариум, хочу посадить в него рыбок, но перед этим надо сделать его красивым – положить большие камни, замки, вот и все.
Кроме того, в аквариуме необходим песок и вода.
Если я просто налью воды и только потом начну все раскладывать, будет беспорядок, камни будет трудно передвигать и т. д. Подход такой: давайте выберем в нашем облаке приложение, которому требуется определенное оборудование, например графический процессор.
Понятно, что установка графического процессора в каждый сервер — мечта, но достаточно дорогая.
Мы будем размещать наши приложения, требующие определенного оборудования, на тех серверах, на которых есть такое оборудование.
Это шаг номер один.
Шаг номер два: давайте возьмем и тщательно проанализируем, стандартизируем наш песок и наши основные приложения — выясним, сколько памяти они будут потреблять, сколько процессора им нужно, в какое время суток, сколько сети им нужно, как они будут работать доставлять данные себе и т. д. Мы будем четко планировать и понимать, например, что эти приложения массовые, готовые к запуску где угодно, и важно соблюдать их требования.
Далее, когда мы произвели размещение нашего песка, мы заполним все свободные области нашими типичными пакетными задачами — задачами машинного обучения.
Как мы знаем, ночью большинство жителей России спят. Поэтому поступает меньше поисковых запросов, процессор освобождается, и хочется его использовать.
Ночь — это расцвет пакетной обработки, ренессанс различных задач, не столь тесно связанных с реакцией пользователя.
Следующий шаг.
Мы запланировали размещение наших приложений в облаке, но как избежать помех между ними? Как сделать так, чтобы те волки, которые запланировали для себя правильные объемы оперативной памяти и процессора, правильно потребляли этот объем? Как сделать так, чтобы им не причинили вреда бедные невинные овцы, которые ничего потреблять не должны, но у которых какая-то утечка памяти, взрыв количества запросов и которые начинают заливать процессор соседними задачами? Нам нужны границы, переборки.
Какие подходы существуют в отрасли? Все слышали, а кто-то, у кого есть ноутбук на Linux, пытался обмануть, настроить каким-то образом свои cgroups, чтобы защитить приложение, установить для него лимиты и чтобы все было более-менее хорошо.
Каков второй общий подход? Давайте просто запустим каждое приложение на отдельных виртуальных машинах.
Накладные расходы мы, конечно, получим: бесплатно ничего не бывает. Мы будем потреблять больше процессора, немного памяти — дело в том, что страницы памяти мы иногда будем пересчитывать по несколько раз.
Многие современные решения от этого страдают меньше, но требуют определенного процессора и т.д. К чему все приходят? На небольшой тонкий слой — контейнер, в котором заключено приложение.
Когда мы начинали эту историю в нашем облаке, Docker еще не был так развит. Его современное оснащение впечатляет – проделана большая работа.
Мы сделали свою очень похожую вещь.
Они назвали его Порту.
Мы хотели легко управлять сотнями, а то и тысячами приложений: чтобы они не мешали друг другу, чтобы процесс настройки был очень простым и чтобы мы в каком-то смысле описали все ограничения приложения, поняли, как работало бы то, что нужно, где нужно хранить данные о том, какой выделенный IP-адрес у этого приложения.
То есть нужно было описать все, что связывает нас с многомерным пространством, запустить этот контейнер и забыть о нем.
С другой стороны, с точки зрения самого приложения, оно практически находится на виртуальной машине.
У него есть собственный небольшой chroot; виден не весь процессор и не вся оперативная память.
Мы получили преимущества в простоте системы развертывания, получили учет ресурсов.
Нас не очень интересует, что приложение делает внутри себя, какие подпрограммы выполняет, что делает с данными и т. д. Нас интересует, что происходило вокруг этого приложения, то есть счетчики из контейнера.
И в качестве еще одного приятного бонуса мы получили возможность запускать вложенные подконтейнеры.
Мы выделили набор ресурсов под какую-то задачу или проблему и дали этому контейнеру имя — вот и всё.
Тогда приложение сможет как-то перераспределить пространство внутри себя и запускать подпрограммы в подконтейнерах, также изолированно.
В результате получилась наша прекрасная подводная лодка, где каждый отсек утеплен.
Если у кого-то где-то течь или что-то взрывается, то взорвалось только там — локально.
Итак, мы все изолировали, все распланировали по кластерам.
Как узнать, где запущены экземпляры приложений? Как решить проблему открытия? Существует несколько подходов.
Один самый типичный: приложение запускается, стучит где-то в центральную точку, говорит - я здесь, я такой-то трафик обслужу, я такой-то типа, у меня все нормально.
Наш подход очень похож на этот. У нас есть интеграция с системой мониторинга.
Когда система видит, что на машине запущено приложение определенного типа, она сохраняет его определенное метаописание.
Когда другие приложения затем будут искать для себя список бэкендов, они смогут использовать это описание.
У нас все в порядке.
Мы на подводной лодке, все изолировали и т. д. Но потом у нас все начинает ломаться.
Давайте представим, что мы работаем в таксомоторной компании.
У нас сотня такси.
Так будет всегда: у одной машины спустило колесо, на другой никто не может ездить, руль странный и т. д. Всегда несколько машин будут сломаны.
Мы должны привыкнуть к тому, что несколько процентов наших приложений — узлов системы — всегда будут сломаны.
Это нужно учитывать на этапах расчета репликаций, нагрузки на каждую ноду и т.д. Что может сломаться? Если мы написали не очень хорошую версию приложения, оно, естественно, вылетает. Обрабатывает определенное количество запросов и вылетает. На тесте не нашли - увидели в облаке.
ОС ломается.
Давайте возьмем новое суперобновление безопасности, которое ни на что не влияет во время выполнения.
Выпустим - приложения начнут вылетать, потому что мы что-то задели в ядре.
Наш сервер выйдет из строя.
Два года работал в аптайме, все было отлично, но стала пропадать оперативка, стали выпадать диски и т.д. Серверы в дата-центре располагаются в стойках.
Питание в стойку подается централизованно, а сеть и несколько проводов подводятся локально.
Все это может выйти из строя, сломаться.
Надо быть готовым к тому, что сломается вся стойка.
Необходимо не размещать критичные части нашего индекса или приложения, которых в нашем облаке работает не очень много, в одной стойке, а хранить их максимально разбросанными.
Стойки, несколько десятков или сотен, объединяются в модули.
Формируется своего рода пожаробезопасный участок ЦОД, чтобы в случае неисправности пострадал не весь ЦОД, а можно было изолировать модуль.
Но иногда выходит из строя весь дата-центр.
Как вы думаете, в какое время года в дата-центрах чаще всего отваливается сеть и страдают каналы связи? — … - Почему весна? Нет, современная оптика прекрасно расширяется и сжимается.
Весна права, но почему? Посев.
Аграрная отрасль просыпается и начинает сносить оптику там, где ее нет. Строители просыпаются и начинают делать работу, которую не смогли выполнить зимой.
Весной страдают каналы связи и т. д. Попробуем классифицировать проблемы нашей аварии.
Ребята уронили спутник на пол, беда.
Один-два процента наших комплектующих, оборудования, что бы оно ни было, вышло из строя.
Это рутинная задача: в нашем таксопарке всегда будет стоять на приколе одна, две или три машины, к этому нужно быть готовым.
Серьезная проблема — это когда 5-7% наших узлов выходят из строя.
Вероятно, какой-то релиз инфраструктурного компонента прошел не так, как мы ожидали.
Может быть, мы что-то сломали в сети, может быть, что-то еще.
В этой проблеме нужно разобраться, но она не критична — наши сервисы продолжают работать, и на этом фрагменте нашей инфраструктуры все в порядке.
Катастрофа – когда выходит из строя 15-20% узлов.
Здесь явно что-то пошло не так; нет смысла выпускать программы, что-то выкатывать или что-то перенастраивать.
Нам нужно ослабить давление и предпринять более активные действия.
Это нежизнеспособная ситуация.
Многие люди, вероятно, знакомы с этим подходом.
Что можно сделать в таких случаях? Начнем с чего-то простого.
Наши машины ломаются.
Их можно сломать просто программно.
Сервер завис.
Нужно уметь это обнаружить, уметь попытаться связаться с этим сервером по IPMI, чтобы что-то с ним сделать.
Мы представляем работу наших систем мониторинга, выявления неисправностей и попыток их устранения, пишем запрос в дата-центр в виде мультика про робота ВАЛЛ-И.
Такие роботы путешествуют по кластеру, стараются все исправить и докладывают в какой-то центральный пункт о происходящем.
Итак, первый подход – авторемонт. Как еще можно справиться с тем, что все время все ломается? Происходит пессимизация бэкендов.
Предположим, у нас есть приложение А, оно ходит на 10 бэкендов приложения Б.
Один из бэкендов вдруг начинает отвечать заметно медленнее, на 100 мс.
Мы можем спокойно разгерметизировать этот бэкенд, начать отправлять на него много запросов — продолжать спрашивать, чтобы следить за его состоянием, но передавать запросы на оставшиеся 9 бэкендов живыми и здоровыми.
Ничего не произойдет – все в порядке.
Мы учим наши приложения быть осторожными, уметь понимать, что под нами находится бэкенд и что с ним что-то случилось.
Здесь другой подход. Приложение А начало отправлять трафика приложению Б во много раз больше, чем мы ожидали.
Удобно иметь возможность отключить часть своего функционала и начать реагировать, может быть, еще вполне корректно, но с гораздо меньшими затратами с точки зрения ЦП.
Например, ищите чуть менее глубоко, если речь идет о поиске.
Мы поднимаем не 1000 документов, а 900 и потихоньку отодвигаем границу.
Вроде бы это не заметно, но мы существенно увеличиваем пропускную способность в тот момент, когда нам это действительно нужно.
Это деградация.
Когда серьезная катастрофа уже произошла, очевидным шагом будет сбалансировать, снять нагрузку.
Мы должны иметь возможность изолировать любой узел, включая весь дата-центр.
Возможно, потребуется удалить оттуда трафик, а затем убрать узел на обслуживание, чтобы что-то с ним сделать.
Как понять, что все наши приложения могут, работают и устроены по этой схеме? Необходимо регулярно проводить учения: отключать узлы, отключать большое количество серверов, отключать дата-центры.
Это должно происходить неожиданно для команд этих приложений — чтобы не было историй о том, что мы манипулируем нагрузкой или еще чем-то.
Это должна быть честная нормальная случайность, но с возможностью быстро вернуть все в исходное состояние.
Мы не ждем прихода весны и того, чтобы экскаватор передвинул один из каналов.
Мы сами отключим его и посмотрим, что произойдет. Давайте разрежем нашу инфраструктуру и посмотрим, что произойдет. 
Хьюстон у нас проблема.
Мы диагностировали проблему до того, что это уже не рутина, а проблема - 5-7% или катастрофа.
С этим обязательно нужно разобраться.
Что ищут типичные поисковые инженеры? Происходит ли сейчас какой-либо релиз или запуск? Наверное, если приложение хорошо работало днями, неделями и все было хорошо, а теперь вдруг, в час дня, время отклика ускользнуло, значит, что-то изменилось.
Вероятно, был релиз, запуск.
Что мы пытаемся рассмотреть? Для меня самый типичный, большой поисковый показатель — это количество запросов.
Казалось бы, в любой момент времени в течение дня мы можем предсказать, сколько вопросов нам зададут. Вчера в 8:30 и сегодня в 8:30 количество запросов будет примерно одинаковое.
Если их на 20% меньше, вероятно, что-то пошло не так.
Время отклика.
Нам всегда приходится во всех компонентах писать, сколько времени занял этап поиска, сколько времени мы обработали запрос и т. д. Мы смотрим на все эти аномалии, агрегируем их, смотрим на определенные квантили.
Качество поиска.
Конечно, пользователи постоянно задают нам миллионы запросов.
Мы задаем себе запросы, сами смотрим на результаты, автоматически разбираем их, анализируем и смотрим, насколько они близки к тому, что мы считаем стандартом.
Интересным показателем последних лет стало распределение по браузерам.
Существует много разных браузеров.
История Netscape Navigator, когда использовать было практически нечего, давно уже в прошлом.
Браузеры появились на мобильных телефонах.
Мы смотрим на то, что происходит в каждом отдельном браузере.
Увеличивается ли количество запросов? За какую сумму мы несем ответственность? Что интересует пользователей, какие темы? И т. д. Вот один из недавних случаев.
У мобильного ВКонтакте были технические проблемы и было хорошо видно, как выросло количество запросов.
Время совершенно не изменилось, качество практически не изменилось, но было видно, что количество запросов в мобильных браузерах увеличилось.
Легко найти, разобраться и т. д. Еще один пример из недавнего прошлого.
Вечером 15 июля в Турции произошло важное новостное событие – политическая ситуация.
Не будем сейчас вдаваться в подробности.
Нас интересует, как это повлияло на Интернет. Люди начали активно что-то искать.
Голубая линия показывает, что происходило в это время неделю назад, а темно-синяя линия показывает, что происходило в настоящее время.
Мы видим резкий всплеск интереса – в мире что-то произошло.
Давайте посмотрим на наш типичный график времени ответа.
Нам очень нравится смотреть время отклика в квантилях: вырезаем себе 100 мс, 200 мс и т. д. разными цветами.
Мы видим, что по времени ответа за указанный период времени ничего не произошло.
А вот наша генерация трафика в ежедневном масштабе.
Мы также видим, что произошло неделю или две назад. Простым аналитическим путем мы поняли, что это внешнее событие.
Потом, как и все, пошли смотреть новости.
Мы видели, что происходит. Я добавил коллег, с которыми работаю каждый день.
У нас в поиске следующая парадигма: в любой момент времени мы можем спрогнозировать, что хотим построить такой-то ЦОД, потратить определенную сумму денег, купить кучу оборудования, но за короткий промежуток времени не будем уметь собрать крутую, интересную, хорошую команду.
Поэтому основная ценность здесь, добавил я.
Итак, мы спроектировали наш дата-центр сверху донизу, заполнили его приложениями, разделили их, изолировали, нашли их все, поняли, что люди должны туда заглядывать, поняли, что нам нужен мониторинг и что нужно делать в этом плане.
Зритель: — Ваши показатели отслеживаются автоматически или за графиками следят специально обученные люди? Олег: — Конечно, все автоматизировано.
Мы получаем уведомление, а затем можем пойти и посмотреть, является ли это какой-либо проблемой или катастрофой.
Андрей Стыскин, руководитель отдела поисковых продуктов Яндекса: — Но сложность проблемы там довольно интересная, там много взаимосвязанных показателей.
Если температура повысится, возможно поток запросов увеличился и нагрузка перераспределилась.
Там сложно быстро распознать и локализовать проблему, в этом есть некий креатив.
Но обнаружить, что что-то идет не так, — довольно простая задача.
Зритель: — Денис, компания Startup Makers. Два года назад Google выпустила свое решение с открытым исходным кодом — Kubernetes. Он очень похож на Порту.
Вы смотрели это решение? Олег: — Конечно, нас постоянно вдохновляет то, что делают наши коллеги.
Мы внимательно смотрим и разрабатываем наши решения.
Плюс мы тоже немного подумываем о том, чтобы когда-нибудь открыть что-то в этом духе.
Андрей: — В перерыве мне задали примерно тот же вопрос, но немного о другой составляющей.
Действительно, в Яндексе есть большой синдром НИЗ – придуманный не здесь.
Это происходит не потому, что мы такие тираны, а потому, что нам приходится находить решения проблем, которые одновременно решают западные или другие ведущие компании.
И они еще не успевают выложить свои решения в открытый исходный код к тому моменту, когда они понадобятся нам в готовом виде.
Мы начали разработку Porto и написали для него обширный фреймворк — разумеется, несовместимый с Docker. Хотя там много чего классного сделано.
Зритель: — Docker теперь не единственный.
Андрей: — Да, я имею в виду, что есть много классных привязок, которые мы хотели бы взять и использовать, не записывая их сами.
Но мы сделали так много, и так много нам нужно было сделать много лет назад, когда ничего не существовало, что у нас теперь достаточно собственных проприетарных решений — не совместимых с открытым исходным кодом.
Зритель: — Вопрос не в том, почему вы не используете Kubernetes. Наоборот, молодец, и будет здорово, если получится лучше Google. Сервис Discovery - тема раскрыта не полностью.
Когда появляются контейнеры, эти поды, определенная группа, определенный онлайн — куда они стучат дальше? Я так понимаю там не какое-то хранилище etcd, ключ-значение, а что-то свое? Олег: — Мы предпочитаем подход, когда система мониторинга находит такой контейнер, потому что она все равно хочет мониторить приложение там и т. д. И при этом она собирает метаданные, узнает, какое приложение там запущено, агрегирует их.
и дает другим приложениям возможность найти исходный.
Немного обратный подход – не толкать, а звонить.
Зритель: — Да, по метрикам получается наоборот. Сейчас, похоже, не так много метрик для конкретных контейнеров.
Для вас это как-то расширяется? Есть ли механизм расширения этого? Олег: — Для контейнеров существуют сотни метрик.
Есть около десятка часто используемых.
Но в целом это очень индивидуализированная система.
Зритель: — В Kubernetes есть Kube Dash, множество решений, которые позволяют легко развернуть что-то дома.
И это работает. Например, я установил его на CoreOS. Планируете ли вы представить публике некоторые решения пользовательского интерфейса для облаков, AWS и других, чтобы связать их с сообществом? Олег: - Хороший вопрос, спасибо.
Слушайте, немного истории.
У нас есть некий аналог закона Мура: вообще в истории Яндекса в прошлом каждый раз количество серверов увеличивается на порядок и мы беремся за новую задачу и понимаем, что она нам будет интересна, каждый раз мы начинаем переделывать нашу систему развертывания и все остальное.
Потому что мы накапливаем имеющиеся недостатки.
В пользовательском интерфейсе также есть некоторый прогресс.
Понятно, что когда у нас работает сотня приложений, очень легко написать UI и отслеживать их все.
Но когда у нас 100 миллионов запущенных приложений, уже возникает проблема, как их один раз показать, агрегировать, чтобы ничего не тормозило.
Оно меняется каждый раз.
Что касается планов представить его публике, боюсь, я не могу назвать конкретные даты.
Андрей: «Мы не можем назвать никаких дат, но спасибо правительству нашей страны».
Оно подталкивает нас к таким решениям и говорит: «Давайте вы все, западные компании, разместитесь в РоссииЭ» Конечно, у нас есть планы сделать доступные облака в России на нашем оборудовании, в наших дата-центрах и немного монетизировать оставшиеся мощности, которые у нас есть.
Зритель: - Это очень ожидаемо, я бы хотел это увидеть.
Андрей: — В стране самая дешевая ожидаемая электроэнергия в мире.
Система, которая занимается развертыванием, называется «Няня».
Зритель: — Данил, выпускник МАИ.
Вопрос ближе к риторическому.
Вы всегда говорите, что нужно быть готовым к тому, что система сломается, и нужно быть готовым ее починить.
У вас есть различные методы решения различных проблем.
Можно ли и нужно ли стремиться к тому, чтобы ничего не сломалось по внутренним причинам – не считая внешних? Олег: — Конечно, на всех этапах необходимо тщательно тестировать оборудование перед вводом его в эксплуатацию.
Вам нужно лучше тестировать свои приложения, вам нужен более тщательный подход с образцами для тестирования и т. д. Конечно, вам нужно улучшать свою производительность.
Андрей: - Но оно все равно сломается.
Олег: — Из тысячи серверов один сломанный можно починить вручную.
Из ста тысяч серверов тысячу сломанных будет сложно починить вручную и одним инженером.
Из миллиона серверов.
ну и т.д. Зритель: — То есть в будущем нельзя будет сказать, что от этого можно безопасно защититься? Олег: — Можно попытаться снизить показатели, но рассчитывать на это не стоит. Зритель: — Ярослав Нечаев, Фонд Бруно Кесслера.
О Порту.
Много ли накладных расходов в Порту и дороги ли все эти функции, такие как вложенные контейнеры и изоляция? Олег: — В этом плане «Порту» очень похож; в каком-то смысле это группы на стероидах.
То, что дает пак cgroups, примерно то же самое, что дает Порту.
Зритель: — Алексей Ушаровский, Сбербанк Технологии.
Вы упомянули упражнения.
Можете ли вы рассказать подробнее, насколько они эффективны и в чем заключаются? Правильно ли я понимаю, что упражнение — это когда внезапно включается пожарная сирена, весь дата-центр уходит вниз, а потом возвращается на место? Олег: — Это больше похоже на плановую посевную кампанию.
Мы самостоятельно выбираем кусок инфраструктуры, который сломаем себе, с тем небольшим условием, что сможем очень быстро вернуть его в рабочее состояние.
Это единственное отличие упражнений от реальных срывов.
Далее мы смотрим, как ведут себя наши приложения, большие проекты и т. д. У нас есть комплекс плановых работ, в ходе которых мы смотрим, как мы деградируем в случае выхода из строя некоторых частей нашей инфраструктуры.
Андрей: — Здесь есть интересный и важный момент. Например, когда мы эмулируем перерезание кабеля с дата-центром и происходят упражнения для всех сервисов - и в этом дата-центре в данный момент можно поменять диски, сделать что-то еще.
Итак, все это синхронизируется с плановой работой.
по модернизации машин в дата-центрах и позволяет получить информацию о том, что, скажем, сервис Яндекс.
Музыка не выдерживает отключения одного дата-центра.
После этого необходимо спланировать инфраструктурные изменения.
Олег: — Наши коллеги из НОК, сетевые операторы, очень любят совмещать свою работу с нашими учениями.
Потому что некоторые аппаратные средства, работающие 24/7/365, очень удобно на время вывести из строя.
Затем вы можете внести некоторые обновления.
Это еще одна важная часть сетевой инфраструктуры.
Зритель: — Владимир Цитис.
При анализе диагностики неисправностей Яндекс использует исключительно естественный интеллект или существуют какие-то инструменты на основе искусственного интеллекта? Олег: - Хороший вопрос.
Каждый наш узел контролируется: и приложение, и мы пытаемся следить за нашим оборудованием.
Допустим, какой-то индикатор выходит за граничные условия, что-то происходит не так.
И тут есть какая-то умная агрегация: если в какой-то части дата-центра температура повысилась на 90% серверов, то, наверное, это не 90% серверов.
Теги: #Хранение данных #Сетевые технологии #облака #инфраструктура #ИТ-инфраструктура #дата-центры #Облачные вычисления #облачные технологии #эксплуатация #Поисковые технологии #облачный хостинг #инфраструктурные решения #упражнения
-
Определение Блоггинга
19 Oct, 24 -
Слухи О Возможностях Apple Ipad 3
19 Oct, 24 -
Форклюзия
19 Oct, 24 -
Выделим Суть Новости. Опыт Яндекса
19 Oct, 24 -
Хабралента Два Ноль
19 Oct, 24 -
Так Зачем Же Внедрять Erp-Системы?
19 Oct, 24
