Компания Яндекс — Технологии — Дата-центры
Когда в 1997 году был открыт сайт www.yandex.ru, для его работы достаточно было одного сервера, установленного под столом одного из первых разработчиков Яндекса, Дмитрия Тейблюма. Вскоре после объявления об открытии появился второй сервер, а когда понадобилось установить ещё один, выяснилось, что места под столом хватает либо на три сервера Яндекса, либо на две ноги Дмитрия.До мысли о создании собственных дата-центров Яндексу в тот момент было ещё далеко — индекс русскоязычного интернета целиком умещался на одном SCSI-диске размером 4Гб, а вся команда портала составляла около десяти человек, работавших в компании CompTek. Поэтому серверное оборудование Яндекса в первые три года его работы было размещено в дата-центре компании «МТУ-Интел». К моменту создания ООО «Яндекс» в 2000 году Яндекс арендовал четыре стойки в «МТУ-Интеле», где размещалось около 40 собственных серверов Яндекса. Эти несколько десятков серверов и стали основой первого самостоятельного дата-центра Яндекса, который расположился в первом офисе компании — в Москве, на улице Вавилова, в вычислительном центре Российской академии наук.Сегодня того, самого первого, дата-центра уже нет, а Яндекс поддерживает разветвлённую и независимую от офисов сеть дата-центров, которая позволяет обеспечивать пользователей Яндекса качественными сервисами в режиме 24х7 с высокой скоростью доступа. В 2005 году в Яндексе шутили, что департамент эксплуатации компании потребляет серверы на завтрак, обед и ужин, устанавливая в дата-центры по три сервера за день — сегодня эта цифра ещё больше, и растёт с каждым днем.
В дата-центры Яндекса непросто попасть, и большинство сотрудников Яндекса даже не знают, где дата-центры находятся. Те, кто работают там каждый день, видят примерно такую картину:
Стойка с серверами. В одну стойку можно установить до 80 серверов, к которым подключены провода.Каждый сервер подключён двумя проводами. Один для управления, другой — для передачи данных.
Сетевой центр с оптическими кабелями.
Модуль c двумя рядами стоек с серверами.
Так стойка с серверами выглядит сзади.
Серверный шкаф.
Часть системы вентиляции и охлаждения дата-центра.
Маховики, которые накапливают энергию на случай отключения электричества (DRUPS). Генерируют электричество, давая возможность запуститься дизелям.
Щиты электрораспределения энергомодуля, которые являются частью решения на DRUPS.
Система пожаротушения. На всякий случай.
Так выглядит система охлаждения дата-центра снаружи.
Энергоцентр, в котором находятся DRUPS и топливохранилище. По сравнению с дата-центром это внушительное здание — всего лишь маленький домик.
yandex.ru
Как Яндекс строил дата-центр с нуля / Яндекс corporate blog / Habr
Этой весной мы получили разрешение на эксплуатацию нашего нового дата-центра. Первого, для которого всё, даже здание, команда Яндекса спроектировала и построила с нуля. За те 18 лет, которые люди ищут в интернете Яндексом, мы прошли большой путь от сервера под столом одного из наших разработчиков до постройки дата-центра, где используем оборудование собственной разработки. По дороге у нас появилось несколько дата-центров в России, в которые мы перестроили прекратившие когда-то свою работу заводы и цеха.Когда мы выбирали место, где можно строить дата-центр с нуля, холодный климат был одним из важнейших факторов. Но именно в процессе этой стройки мы нашли технологическое решение, которое позволяет нам эксплуатировать ДЦ в более теплом климате. Сейчас мы планируем построить наш следующий дата-центр во Владимирской области. И теперь у нас есть все возможности создать в России дата-центр, который станет одним из самых передовых в мире.
В этом посте мы хотим рассказать, как мы проектировали ДЦ, с какими сложностями столкнулась наша команда в процессе строительства, как проходила пуско-наладка, в чем особенности дата-центров Яндекса и как устроена рекуперация тепла, о которой вы уже могли слышать.
Необходимость
Как мы уже рассказывали, архитектура сервисов компании позволяет организовывать резервирование на уровне дата-центров, а не подсистем, что дает бóльшую гибкость при выборе решений и позволяет снизить избыточность систем и соответствующие затраты.
Дата-центр и серверная архитектура проектируются как единая система, поэтому параметры функционирования инженерных систем могут отличаться от общепринятых — можно, в частности, использовать альтернативные источники бесперебойного питания и отказаться от громоздких технических решений по охлаждению за счет расширения допустимого температурного диапазона. Все это ведет к повышению эффективности и понижению совокупной стоимости владения инфраструктурой.
Одна из метрик эффективности работы дата-центра — PUE. Впрочем, говоря о наших ДЦ, мы не собираемся ставить ее во главу угла. Во-первых, нам незачем меряться PUE с коллегами, а во-вторых, существующие разногласия в методике измерения этого параметра не позволяют проводить сравнение даже между нашими собственными ДЦ.
Однако сама сущность параметра PUE исключительно важна для Яндекса. Коммерческие дата-центры могут позволить себе не скупиться на строительство и оснащение, понимая, что в конечном итоге за все заплатит клиент. В нашем случае мы являемся сами себе клиентом, поэтому низкая совокупная стоимость владения ДЦ (ТСО), пожалуй, самый важный критерий при выборе решений в компании.
И конечно же, нашей команде хочется не только увеличивать площади под установку новых стоек, но и чувствовать профессиональную гордость за то, что мы делаем.
Идея
До начала проектирования финского дата-центра мы успели построить (и частично закрыть) 10 дата-центров. При строительстве очередного ДЦ мы каждый раз старались использовать наиболее интересные решения, которые появлялись на рынке в тот момент. Это привело к большому разнообразию реализаций, зато теперь позволяет нам выбирать наилучшие решения не на основании рекламных каталогов, а используя накопленный в компании опыт и результаты собственных экспериментов.
Камера адиабатики и каплеуловители за ней
Те из вас, кто изучал конструкцию ДЦ Facebook, которая неоднократно публиковалась в интернете, найдут много аналогий. Но надо сразу оговорить, что это только совпадение. Когда концепт нашего ДЦ был уже готов, нам довелось съездить в гости в один из ДЦ социальной сети, и мы с удивлением узнали, что коллеги только что реализовали проект, практически идентичный нашему.
Конечно же, специфика Орегона и Финляндии повлияла на различия, но принцип обдува воздухом с улицы настолько прост и очевиден, что в сходстве концепций нет ничего удивительного. С другой стороны, мы с удовольствием отметили, что кое в чем наш проект будет даже интереснее.
Дизель-генераторы и динамические ИБП
Например, менее сложная система адиабатического охлаждения и использование динамических роторных ИБП (ДРИБП) вместо сочетания дизелей и классических батарейных ИБП.
Как видно из иллюстрации, холодный воздух попадает с улицы (с правой стороны картинки) в камеры смешения, откуда после фильтрации нагнетается вентиляторными стенами через модуль увлажнения вниз, в холодные коридоры.
Первый ряд фильтров
Второй ряд фильтров и приточные вентиляторы
Из горячих коридоров воздух попадает в пространство второго этажа, играющего роль своеобразного буфера, откуда часть направляется в камеры смешения.
Камера смешения внешнего и отработанного воздуха для достижения оптимальной температуры
Не используемый в смешении горячий воздух вытяжными вентиляторами выводится с другой стороны здания.
Внутри «горячего коридора»
Решение действительно очень простое, однако оно подразумевает использование оборудования, которое умеет работать при соответствующей температуре и влажности, что трудно достижимо для коммерческих дата-центров.
Серверы в работе
Как показал первый опыт эксплуатации, у нас есть еще значительный потенциал для улучшений. Мы поняли, что можно упростить конструктив здания, полностью отказаться от использования воды в ДЦ и, наконец, расширить географию строительства вплоть до центральных регионов России. Благодаря этому мы сможем построить наш следующий дата-центр во Владимирской области, климат которой значительно теплее финского.
Почему Финляндия?
Этот вопрос является вторым по популярности, на который нам приходится отвечать. Ответ же настолько прост, что рассказывать о нем даже немного неловко.
Дело в том, что неофициальным талисманом Яндекса является лось («Наш лось!»). Во всем мире есть две страны, в которых ценят и лелеют этих животных, — Швеция и Финляндия. Но так как в Швеции уже построился Facebook, нам оставались наши северные соседи. Из всей страны мы выбрали город, на гербе которого был лось. Так жребий был брошен, и мы решили строиться в Мянтсяля.
Однако одного лося все же недостаточно. Важнейшими критериями, по которым производился отбор на тот момент, были доступная электрическая мощность (высокостабильная энергосеть Финляндии построена много лет назад для ЦБК, которые чувствительны к качеству питающего напряжения), хорошая доступность оптических линий, жаждущие работы инженеры и, конечно же, холодный северный климат, в условиях которого можно было отказаться от чиллеров и честно использовать любимый фрикулинг.
Нельзя не отметить, что работа с местными партнерами оказалась истинным удовольствием. Так, разрешение на строительство получается в течение одного месяца (sic!), а дорога, линии водо- и теплоснабжения и электропередач возникают на границах участка в невероятно короткие сроки.
Кроме того, мы реализовали с местными властями, так сказать для души, проект по рекуперации тепла. Установив теплообменники в месте выброса отработанного горячего воздуха, мы нагреваем теплоноситель и передаем его в городскую систему теплоснабжения. Для муниципалитета доводить подогретую таким образом воду тепловыми насосами до необходимой температуры оказалось дешевле, чем строить дополнительную котельную для новых районов города.
Собственно теплообменники
Это решение мы представили в марте на выставке CeBit (в этом году объединенной с Datacenter Dynamics), и оно привлекло к себе огромное внимание — тематика энергоэффективных технологий сегодня очень актуальна. 27 мая Мянтсяля получила приз Best Heat Pump City in Europe.
Проектирование
Если не касаться содержания документации, то уже в процессе проектирования мы столкнулись с некоторыми интересными особенностями работы в Финляндии.
Там нет такой жесткой формализации оформления и состава документов, к которой мы привыкли. Говоря совсем просто, детализация документации должна быть ровно такой, чтобы исполнитель смог получить всю необходимую информацию. В какой-то мере облегчило общение с разрешительными органами, которые выражали свое одобрение, основываясь на том, как они поняли документ, не уделяя внимания полноте и оформлению.
Под крышей, где происходит забор воздуха
Некоторые из представителей властей вообще не стремились выразить свое личное мнение о проекте. Пожарный инспектор, например, был удовлетворен, если на представленном пакете документации стояла виза сертифицированной компании-консультанта. Такая подпись для него значила, что проект уже проверен и соответствует всем местным нормативам.
С другой стороны, большинство мелких подрядчиков отказывались даже оценивать стоимость работ, если в чертежах не было прописано все до последнего винтика. Такой подход озадачил не только нас, но и наших партнеров из других стран. В результате очень многие чертежи содержат куда больше информации, чем мы ожидали бы увидеть.
При реализации проекта мы пользовались трехмерной моделью здания, в которой было расставлено все оборудование, проведены кабельные трассы и т. д. На привыкание к этому инструменту потребовалось какое-то время, зато потом работать с моделью оказалось очень удобно — удавалось быстрее решать некоторые проблемы при сведении систем, которые были не сразу очевидны в двухмерном представлении.
Также наши коллеги научили нас пользоваться онлайн-системой сбора комментариев по проекту, так что можно было быть уверенным, что замечания не потеряются и будут регулярно просматриваться на проектных встречах.
Строительство
О необычайных приключениях русских заказчиков в Финляндии можно было бы написать отдельную большую статью. Но главный вывод прост: успех подобных проектов определяется умением преодолевать различия в менталитете и культуре участников. И самая большая ответственность лежит на нас в момент выбора партнера, который сможет эти различия примирить. Примеров можно привести очень много. Самые забавные, пожалуй, следующие.
Начало строительства
Финская стройка работает с семи утра до трех-четырех дня. Представьте наше недоумение, когда российская команда, возвращаясь с обеда, видит дружную толпу строителей, уже закончивших на сегодня трудовую вахту. Оставшиеся полдня мы наблюдаем почти пустынную стройплощадку, и на этом фоне несколько странно выглядят заявления финских партнеров, сетующих на то, что они никак не успевают уложиться в сроки, хотя и очень стараются.
Возведение стальных конструкций
На уровне рядового рабочего финское качество строительства не слишком сильно отличается от привычного нам. Существенное приращение качества происходит при добавлении нескольких уровней профессиональных бригадиров, контролеров и руководителей. И хотя цена «менеджерской составляющей» приводит в шок, результат получается очень хороший.
И конечно, нельзя не упомянуть легендарный финский июль, когда вся страна бросает работу и начинает отдыхать. В некоторые компании бессмысленно даже звонить — в офисе нет ни единой души. Так как мы привыкли считать эти редкие погожие дни идеальным временем для завершения многих строительных работ, такое отношение со стороны подрядчиков для нас выглядело как откровенный саботаж.
Каркас готов
Но самым главным уроком этого строительства стало осознание того, что проекты такого масштаба требуют совершенно особого подхода. То, как ты организуешь стройку, оказывает несоизмеримо больший эффект на результат проекта, чем то, что ты строишь. Мы увидели, что в другой стране люди работают иначе. Это не значит, что они что-то делают плохо, — просто по-другому. Кажется, нам удалось понять друг друга, и главное, что мы вместе получили отличный результат.
Пусконаладка
Пожалуй, основное, что отличает этот проект от всех предыдущих, — понимание с самого начала важности полноценной пусконаладки (ПНР). Для качественной сдачи объекта, а следовательно, для минимизации проблем во время эксплуатации мы еще в период проектирования держали в голове целую фазу проекта под названием Commissioning. Скрепя сердце мы отдали Commissioning два месяца, зная, что на эти два месяца будет отложен ввод в эксплуатацию уже готового ДЦ, и одновременно понимая, что в дальнейшем это окупится сторицей. И в самом деле, в процессе пусконаладки было найдено некоторое количество недостатков. Ничего серьезного, но дополнительные хлопоты службе эксплуатации они бы принесли.
Не только российский, но и мировой опыт показывает, что пусконаладка ДЦ — все еще непривычное явление. В лучшем случае разрозненные поставщики приносят программы индивидуальных испытаний, а затем группа эксплуатации совместно с генеральным подрядчиком прогоняет пять-шесть самых критичных ситуаций, как правило связанных с запуском дизелей и переключением вводов.
Полноценное описание процесса заслуживает отдельного рассказа, поэтому здесь только упомянем, что мы запланировали и провели все пять ступеней ПНР с тщательным документированием результатов.
Пусконаладку выполняла специально обученная команда. Формально они были сотрудниками генерального подрядчика, однако фактически действовали независимо, оценивая качество работ, в том числе и своих коллег. Огромное участие в пусконаладке принимала и уже сформированная к тому времени служба эксплуатации. Естественно, и представители московского офиса пристально следили за результатами испытаний.
Такой подход был сравнительно новым для нас. Мы по достоинству оценили его возможности и теперь даже не представляем, как без него запускаться.
Эксплуатация
Интересно, что набор и подготовку службы эксплуатации мы начали задолго до монтажа инженерных систем. Это позволило нам потратить больше времени на поиск действительно хороших специалистов, частично привлечь их даже на период проектирования: к сожалению, это привело к изменению проекта в самый последний момент, но зато уменьшило оторванность проекта от потребностей живых людей, которые проведут в этом ДЦ не один год. На некоторых этапах пусконаладки служба эксплуатации выполняла тестирование своими силами под наблюдением ответственной стороны.
Вход в офисную часть
В Финляндии большое внимание уделяется вопросам сертификации специалистов — некоторые виды работ выполнять без подтвержденной квалификации просто незаконно. Второй серьезный момент — это соблюдение норм охраны труда и экологии. Поэтому в нашей команде соответствующий специалист появился вторым по счету, и мы могли быть уверены, что не нарушим жесткие нормы законодательства даже случайно. Также значительный временной лаг позволил нам провести все требуемое обучение и сертификацию еще до начала эксплуатации, то есть вообще «без отрыва от производства».
Обратная сторона здания дата-центра
В целом хочется отметить большую заинтересованность будущих дежурных в своей работе. Мы уверены в команде, которую набрали, несмотря на то что дата-центр, тем более такого уровня, большинство ребят увидели в первый раз.
Нельзя не отметить, что теперь департамент эксплуатации Яндекса становится по-настоящему международным коллективом. Это не только позволит компании продолжать развивать новые навыки совместной работы, но и обяжет поднимать планку для уже существующей службы.
Что дальше?
Дальше у нас в планах расширение уже построенных площадок, а также строительство нового дата-центра, который обещает быть еще более прогрессивным. Наша цель — сделать его одним из лучших в мире.
habr.com
Где находится сервер «Яндекса»? Официальная информация и исследования пользователей
Система «Яндекс» в России — самая значительная. Это не только удобный поисковик, но и облачное хранилище данных, электронная почта, навигационные карты, служба заказа такси и многое другое. А где же хранится весь этот объем информации системы? Где находится сервер «Яндекса» физически? В этой статье мы попробуем это выяснить.
Что говорит «Яндекс»?
Печальный факт: представители самой корпорации не указывают на своих ресурсах, где находится сервер «Яндекса» физически. Широкому кругу аудитории известен только один факт — дата-центры в своем большинстве открыты в России. Некоторые из них — в столице.
Кроме того, даже подавляющее число сотрудников компании не знает, где конкретно находятся дата-центры «Яндекса». А уж попасть туда затруднительно не только постороннему человеку, но даже и работнику этой корпорации.
Где был первый сервер «Яндекса»
А вот своей историей сотрудники и представители компании охотно делятся. Где находился главный сервер «Яндекса» в 1997 году, когда был запущен сайт? Вы удивитесь, но он просто стоял под столом у одного из первых разработчиков — Д. Тейблюма. Вскоре после открытия сайта «Яндекс.ру» понадобилось установить второй сервер, а потом уже и третий. Тогда-то сотрудники «Яндекса» задумались о расширении.
Нет, дело не шло об открытии собственного дата-центра. В этом не было необходимости: команда «Яндекса» исчислялась всего десятью сотрудниками, а для умещения индекса всего русскоязычного интернета вполне хватало 4 Гб SCSI-диска. Отчего в первые три года работы ресурса серверы размещались в одной стойке дата-центра «МТУ-Интел».
В 2000-м, когда было создано ООО «Яндекс», оно арендовало уже четыре стойки у данной компании. Это 40 личных серверов. Они, кстати, и стали основой уже для собственного дата-центра, который был открыт в первом офисе ресурса, расположенном на ул. Вавилова в Москве (вычислительный центр РАН — Российской академии наук).
Сегодня эта «серверная» уже не функционирует. Современный «Яндекс» поддерживает масштабную сеть дата-центров, которые работают независимо от офисов. Именно они в настоящее время помогают пользователям ресурса 24 часа в сутки и 7 дней в неделю иметь высокоскоростной доступ к необходимой информации. Подумать только, сегодня департамент эксплуатации «Яндекса» устанавливает в день по 2-3 сервера в собственных дата-центрах! И этот показатель не окончательный — корпорация не думает останавливаться в своем развитии.
Какой он — дата-центр «Яндекса»?
Где находится сервер «Яндекс.диска», представители компании нам, увы, не расскажут. Зато они с радостью готовы поведать, как выглядит их стандартный дата-центр изнутри:
- Самая главная и большая часть — это стойки. В одну из них можно установить до 80 серверов.
- К каждому серверу подключены строго два провода. Один — для управления, другой — для передачи информации.
- Все составляющие сетевого центра сообщаются между собой оптическими проводами, которые проложены так аккуратно, что вызовут зависть у любого перфекциониста.
- Два ряда стоек с серверами объединяются в один модуль. Между ними — проход для специалистов дата-центра.
- Очень важна система охлаждения и вентиляции всей системы, а также щиты электрораспределения энергетического модуля.
- Обязательная часть дата-центра — маховики, которые копят в себе энергию на случай внезапного отключения электричества. Именно они предоставят возможность запуститься дизелям в аварийной ситуации.
- Рядом с центром — топливохранилище.
- В любой такой «серверной» предусмотрена система пожаротушения.
Как найти серверы компании
Если вы самолично хотите определить, где находится сервер «Яндекса», то для этих целей проще установить на свой компьютер соответствующее ПО. Пользователи советуют программы Traceroute, Neotrace. Мы же рекомендуем вам устанавливать подобное ПО только в случае, когда вы на 100 % уверены в его безопасности.
По словам опробовавших приложения, данные программы представляют исчерпывающую информацию о физическом местонахождении серверов «Гугла», Yahoo, «Яндекса». Пользователю доступна карта, информация о координатах объекта (долгота, широта), его адрес.
Где именно в России находятся серверы «Яндекса»
В заключение представим информацию от пользователей, самостоятельно выяснивших местонахождение серверов системы. Однако данные эти неофициальны, поэтому доверять им на 100 % не имеет смысла.
Итак, где находится сервер «Яндекса»? Все найденные дата-центры расположены в Москве:
- Ул. Вавилова, 40а.
- Ул. Краснознаменная, 2.
- Ул. Краснознаменная, 12.
- Ул. Курчатова, 1.
- Ул. Нежданова, 2а.
Некоторые исследователи утверждают, что серверы находятся в столице также на ул. Льва Толстова и на ул. Самокатной, а также в городе Ивантеевка.
Где точно находятся серверы «Яндекса», широкой общественности доподлинно не известно. Представители компании утверждают, что большинство их дата-центров сосредоточены на территории Российской Федерации. Пользователи же предлагают программы, которые способны определить точное (до адреса) расположение серверов того или иного ресурса, и даже делятся результатами своих исследований в Сети.
fb.ru
Экскурсия в дата-центр Яндекса — Блог Яндекса
29 ноября 2013, 13:11
Яндекс поддерживает разветвлённую и независимую от офисов сеть дата-центров, которая позволяет обеспечивать пользователей качественными сервисами в режиме 24х7 с высокой скоростью доступа. Несколько лет назад в Яндексе шутили, что департамент эксплуатации компании потребляет серверы на завтрак, обед и ужин, устанавливая в дата-центры по три сервера за день. Сегодня эта цифра гораздо больше.
Вот как выглядит дата-центр Яндекса изнутри:
Стойка с серверами. В одну стойку мы можем установить до 80 серверов, к которым подключены провода. Очень много проводов.
Каждый сервер подключён двумя проводами. Один для управления, другой — для передачи данных.
Сетевой центр с оптическими кабелями.
Модуль c двумя рядами стоек с серверами.
Так стойка с серверами выглядит сзади.
Серверный шкаф.
Часть системы вентиляции и охлаждения дата-центра.
Маховики, которые накапливают энергию на случай отключения электричества (DRUPS). Генерируют электричество, давая возможность запуститься дизелям.
Щиты электрораспределения энергомодуля, которые являются частью решения на DRUPS.
Система пожаротушения. На всякий случай.
Так выглядит система охлаждения дата-центра снаружи.
Энергоцентр, в котором находятся DRUPS и топливохранилище. В масштабах к дата-центру это внушительное здание всего лишь маленький домик.
yandex.ru
Новый датацентр / Яндекс corporate blog / Habr
Количество наших пользователей и объемы информации растут, и на прошлой неделе мы запустили новый, седьмой по счету, датацентр. Наш новый датацентр расположен в Мытищах, имеет подведенную мощность 4МВт, и в нем можно разместить более 6000 серверов. В нем 4 очереди, каждая по 1МВт. Сейчас готовы к работе две, а еще две строятся.Датацентр начинается с выбора помещения, где есть достаточно электроэнергии, куда можно провести оптику для связи и договориться о долгосрочной аренде помещения. После начинается ремонт помещения.
Тут видно, что на полу стоят ножки, на которые впоследствии ляжет фальшпол. А 60 см под полом — свободно для продува воздуха от кондиционеров. Справа уже видно помещение, где фальшпол уложен на ножки.
После строительной готовности помещения расставляются кондиционеры, ставятся стойки, проводится электричество и СКС, центральный ряд плиток фальшпола меняется на решетки, из которых будет дуть холодный воздух из кондиционеров в холодный коридор. Холодный воздух из этого воздушного коридора будет захватываться вентиляторами серверов, прогоняться сквозь них и охлаждать. В стойки расставляются свитчи и KVM.
Все знают, что у нас регулярно бывают перебои с электричеством, а сервисы у нас должны работать круглосуточно. Поэтому мы обеспечиваем датацентры ИБП (источниками бесперебойного питания). Так что при отключении внешнего питания наш датацентр сможет проработать на аккумуляторах небольшое время. Но электричество нередко отключают и на много часов. Для таких случаев каждый наш датацентр оборудуется и дизель-генератором. Дизель-генератор работает на солярке и может обеспечивать питанием датацентр продолжительное время (если не забывать подвозить топливо). Обеспечением работы дизель-генераторов, кондиционеров, электричества занимаются инженеры Службы Главного Инженера департамента по общим вопросам.
Чтобы у серверов была сеть, им нужно ее обеспечить. К каждому датацентру мы прокладываем минимум 2 оптических канала, и, конечно, все наши датацентры подсоединены к нашему московскому оптическому кольцу. Это делается для защиты от экскаваторов, которые почему-то копают именно в тех местах, где лежит оптоволокно. В самих же очередях сеть приходит вот в такие свитчи, только шасси от которых весит 55кг, не считая внутренностей. После сеть подводится к свитчам, которые стоят в каждой стойке, а от них уже разводится по серверам. Чтобы было проще коммутировать и отслеживать, что и куда подключено, используются патч-корды разного цвета.
Казалось бы, пора ставить сервера? Не сразу. Прежде, чем сервер будет установлен в стойку, его нужно принять, распаковать из коробки, разобрать, чтобы инвентаризовать память, жесткие диски и сам корпус, затем снова собрать, чтобы установить в стойку и подключить, а все действия аккуратно провести по складской программе, чтобы мы знали, где и что у нас стоит. Аналогичные действия производятся и со свитчами, с KVM’ами и другим оборудованием, которое используется в датацентре. Все эти действия проводятся на складе, который есть в любом датацентре. Отвечают за это инжереры датацентра из инфраструктурного отдела департамента эксплуатации. Это очень ответственные люди, у которых всегда обязан быть порядок в хозяйстве. А все полки подписаны. Даже те, которые непонятны.
Вот теперь можно ставить сервера. После их установки на них устанавливается операционная система и необходимое ПО в полуавтоматическом режиме, чем обычно занимаются дежурные администраторы. После чего сервера передаются в эксплуатацию системным администраторам. Сисадмины устанавливают то, чего не хватает и окончательно настраивают сервера перед вводом их в продакшн. В окончательную настройку входит также настройка мониторинга, который будет оповещать нас о проблемах на сервере. За мониторингом круглосуточно следят дежурные администраторы, которые оповещают ответственных админов о проблемах с их серверами и являются руками админов в случаях, когда надо поменять винчестер, подключить KVM или перегрузить намертво зависший сервер.
А вот такой охранник стоит на входе в наш ДЦ:
habr.com
Как и для чего Яндекс отключает собственные дата-центры / Яндекс corporate blog / Habr
Раз в неделю Яндекс отключает один из своих дата-центров. Мы называем это учениями. Что это такое? Как возникло? Зачем мы это делаем? А не диверсия ли это? Насколько это опасно? На эти вопросы мне регулярно приходится отвечать как внутри, так и снаружи компании. Сегодня я решила прояснить все эти вопросы разом.Сейчас у нас несколько собственных дата-центров, в которых располагается несколько десятков тысяч серверов и сетевое оборудование. Учения — это моделирование реальной жизненной ситуации, при которой мы теряем или весь дата-центр или его часть.
Для начала предлагаю обратиться к истории и попытаться понять, как мы пришли к такому решению. Все привыкли к тому, что наши сервисы работают всегда, без перерывов на обед и профилактику. Серьезные сбои происходят настолько редко, что каждый из них становится заметным событием.
Когда сервера были большими, а дата-центры маленькими…
В 2000 году Яндекс арендовал четыре стойки в «МТУ-Интеле», где размещалось около 40 собственных серверов Яндекса. Эти несколько десятков серверов и стали основой первого самостоятельного дата-центра Яндекса, который располагался в первом офисе компании — в Москве, на улице Вавилова, в вычислительном центре Российской академии наук. В те годы все сервера и вся сетевая инфраструктура были в одном дата-центре. Несколько лет нам везло и никаких ЧП не случалось. Все изменилось в 19 часов 12 ноября 2004 года. В тот момент за пару минут до начала второго тура игры «Кубок Яндекса» в здании Вычислительного центра Российской Академии наук (ВЦ РАН) в Москве на улице Вавилова, где располагается компания, внезапно отключилось электричество.
Это произошло из-за неполадок в оборудовании поставщика электроснабжения. На тот момент у нас уже было 2 дата-центра, но все сетевое оборудование, обеспечивающее связность наших серверов с внешним миром, было в отключённом дата-центре. В тот вечер сервисы Яндекса не работали несколько часов.
Это была первая большая авария, потом были еще и другие:
- пух забивался в кондиционеры, и они начинали греть, а не охлаждать дата-центры, сервера приходилось отключать;
- отключение дата-центров по питанию по разным и совершенно невероятным причинам, начиная от того, что арендодатель забыл вовремя оплатить счет за электроэнергию, кончая тем, что кошка забралась в трансформаторную будку и устроила короткое замыкание;
- были потопы в дата-центрах;
- конечно, не обошлось и без нашего любимого персонажа — экскаваторщика, ловко и метко копающего в местах, где лежит наш оптоволоконный кабель.
Очевидно, что в таких условиях мы быстро поняли, что можно рассчитывать только на свои силы и уметь жить в условиях N-1 дата-центр. Мы начали над этим работать в 2004 году, и тогда многие решения, которые кажутся очевидными и простыми сейчас, были для нас в новинку.
Развитие инфраструктуры
Начали с инфраструктуры. После событий 12 ноября наш первый дата-центр был оборудован дизель-генераторной установкой, а второй получил внешнюю связность не только с первым дата-центром, но и связь с внешним миром. Таким образом, в теории стало возможным как-то обслуживать пользователей в условиях, когда один из двух дата-центров не работал. Было понятно, что до того, чтобы это можно было сделать на практике, надо еще вложиться в избыточность, чтобы не умирать под нагрузкой, много чего исправлять в архитектуре проектов и продолжать развивать инфраструктуру.
Интересный факт: c той поры все наши дата-центры оборудованы ДГУ, которые нас не один раз выручали. Как известно, наши основные операционные системы — Linux и FreeBSD, а когда дата-центр работает на ДГУ, то мы шутим, что работаем на Солярке.
Также было решено, что магистральная сеть, объединяющая ДЦ, должна не иметь единых точек отказа. В частности, никакие каналы связи между дата-центрами не должны проходить одними путями. Поэтому первая топология сети, обеспечивающая резервирование, представляла собой кольцо. Тогда каналы соединяли между собой уже три наших дата-центра плюс две точки обмена трафиком с подключением к MSK-IX — в ИКИ и на M9. Со временем магистральная сеть превратилась в двойное кольцо, а теперь все дата-центы московского региона по сути связаны в full mesh. Таким образом, обрыв одного кабеля не влияет на доступность сервисов.
Много усилий ушло на переработку кода наших приложений для работы в новых условиях. Например, мы учили программы складывать пользовательские данные на два сервера и думали, что делать, если один из них становится недоступным: предлагать пользователю загрузить свои данные позже или все же загрузить их на работающий сервер, а потом синхронизировать; патчили модуль ядра IPVS для балансировки нагрузки. Было много раздумий над тем, что делать с базами данных. Например, в MySQL всегда есть один master-сервер, если он не работает может быть два варианта развития событий: переводить сервис в режим «только для чтения», либо писать скрипты, позволяющие быстро сделать master из другого сервера в другом дата-центре. Вспомнить сейчас все, что было сделано тогда, уже не получится, но работы было много.
Подготовительный этап занял около трех лет, за это время мы вложились в дублирование компонент там, где это необходимо и оправдано; для каких-то сервиcов поняли, что переписывать все с нуля — очень дорогая задача и научились деградировать, отрезать менее важную функциональность на время аварий.
К осени 2007 года было понятно, что пора тестировать результаты работы. Как? Конечно, отключать дата-центр по-настоящему в четко обозначенное время, когда все, кому могут быть интересны результаты, были на месте. Сейчас это достаточно распространенная практика: подобные учения проводит большинство крупных игроков со своими дата-центрами, в том числе и многие хостинг-провайдеры. А тогда это был не самый очевидный и достаточно рискованный шаг.
Впервые отключение прошло 25 октября 2007 года, мы прожили без одного из наших дата-центров 40 минут. Первое время у нас не все шло гладко, команды проектов смотрели внимательно на свои сервисы: придумывали, что делать с архитектурой сервисов дальше, писали новые мониторинги, правили баги. С тех пор на вопросы: «Насколько это опасно? А не диверсия ли это?» — я отвечаю, — «Конечно, опасно, нет, не диверсия».
Как проходят учения?
Обычно они проходят раз в неделю по вечерам. Почему именно вечером? Мы сами регулярно про это спорим. Тут много факторов, но можно выделить два. Во-первых, мы во время учений можем что-то сломать, днем это затронет большее количество пользователей и будет заметно снаружи, что плохо, а ночью не все на местах, можем что-то упустить и не заметить, что тоже плохо. Во-вторых, вечером у нас не пик трафика, но и не минимум, можно под нагрузкой посмотреть на поведение сервисов. Иногда время начала работ и продолжительность может меняться. Бывает, что мы совмещаем учения с сервисными работами на сети, которые проводят сотрудники NOC. Поскольку сеть должна работать всегда, регламентные работы в сети дата-центра можно производить только тогда, когда он не обслуживает пользовательский трафик. В этом случае отключение дата-центра может растянуться на несколько часов. Это бывает довольно редко, потому что многие регламентные работы, например, обновление программного обеспечения ToR-коммутаторов (Top of Rack), практически полностью автоматизированы и один сетевой инженер может обновить несколько сотен устройств, запустив пару скриптов. В частности, для этого мы используем RackTables — open source продукт, к созданию которого приложили руку мы сами.
Про время, продолжительность и дату определились, что дальше? Важная часть подготовки — координация выключения дата-центра. C 5 октября 2007 у нас на внутренней вики и с недавних пор во внутреннем календаре всегда есть актуальное расписание учений на ближайшее время. График учений стараемся составлять на несколько месяцев вперед. За день до часа X организаторы рассылают последнее предупреждение на несколько списков рассылки и публикуют анонс во внутреннем блоге. В письме можно найти ссылку на список того, что будет не работать/деградировать, и за чем стоит внимательно посмотреть.
Как происходит отключение? Во время учений мы не выключаем питание серверов в тестируемом дата-центре, а моделируем его отключение с помощью сети. Фактически, на сетевом оборудовании, находящемся на периметре дата-центра, мы выключаем виртуальные сетевые интерфейсы, разрывая сетевую связность. Проще делать это таким образом, так как отключать все сервера по питанию сложнее и в итоге дороже. Если отключать по питанию, то необходимо, чтобы на объекте был персонал, который сможет после окончания Учений все включить, и практика показывает, что оборудование частично не включится, что-то обязательно придется менять. По нашей статистике, до 5% дисков может перестать распознаваться операционной системой после выключения. Ну и, конечно же, самый важный фактор — если что-то пойдет не так, то надо иметь возможность быстро вернуть дата-центр в работу. В нашем случае мы можем сделать это достаточно быстро. Поэтому даже если учения идут не по плану, отваливается какой-нибудь сервис или часть функций, для пользователей в подавляющем большинстве случаев все проходит незаметно.
Разбор полетов
По окончании учений у нас появляется информация о том, что происходило – разбор полетов. Если какие-то сервисы работали незапланированным образом, команды этих сервисов вместе пытаются выяснить, что послужило причиной этому и ставят сами себе задачки.
С каждым разом ошибок всплывает все меньше. Вот, например, недавно мы с небольшим промежутком отключали сначала наш самый старый, а потом самый большой ДЦ. На страничках с итогами отключений нет ни одного тикета с багами. Приятно! Но, конечно, не всегда все проходит так гладко, так как наши сервисы постоянно развиваются и не за всем удается уследить, к сожалению. Но для этого мы и проводим наши тестовые отключения дата-центров.
Нам все еще есть еще над чем работать. Сейчас у нас есть несколько важных задачек. Одна из них — обеспечить непрерывную работу не только наших сервисов для пользователей, но и обеспечить непрерывную работу нашей разработки. Сейчас тестовые и девелоперские среды по большей части не задублированы, и во время учений разработчики вынуждены пить чай и кофе. Сейчас мы ставим эксперименты с OpenStack по миграции – непросто, так как виртуалок и данных много, а междатацентровые линки у нас широкие, но не бесконечные. С другой стороны, быстрое разверытывание виртуальной машинки в iaas с необходимым окружением и данными с помощью скриптов.
Почему мы проводим работы регулярно? Нагрузка постоянно растет, сейчас у нас происходит около 1000 изменений программ в день, архитектура меняется, количество серверов, обслуживающих сервис, меняется, с годами меняются условия жизни — старые дата-центры закрываются, появляются новые. В таком постоянно меняющемся окружении надо продолжать решать задачу — работать в условиях N-1 дата-центр.
habr.com
Яндекс.DNS
Технические подробности
Яндекс.DNS — это бесплатный рекурсивный DNS-сервис. Сервера Яндекс.DNS находятся в России, странах СНГ и Западной Европе. Запросы пользователя обрабатывает ближайший дата-центр, что обеспечивает высокую скорость соединения.
| Базовый | Безопасный | Семейный | ||
| IPv4 | Preferred DNS | 77.88.8.8 | 77.88.8.88 | 77.88.8.7 |
| Alternate DNS | 77.88.8.1 | 77.88.8.2 | 77.88.8.3 | |
| IPv6 | Preferred DNS | 2a02:6b8::feed:0ff | 2a02:6b8::feed:bad | 2a02:6b8::feed:a11 |
| Alternate DNS | 2a02:6b8:0:1::feed:0ff | 2a02:6b8:0:1::feed:bad | 2a02:6b8:0:1::feed:a11 | |
Скорость работы Яндекс.DNS во всех трёх режимах одинакова. В «Базовом» режиме не предусмотрена какая-либо фильтрация трафика. В «Безопасном» режиме обеспечивается защита от заражённых и мошеннических сайтов. «Семейный» режим включает защиту от опасных сайтов и блокировку сайтов для взрослых.
Защита от заражённых сайтов
Яндекс ежедневно проверяет десятки миллионов страниц на наличие вредоносного кода, выявляя тысячи зараженных сайтов. Для этого применяются сигнатурная технология Sophos и собственный антивирус Яндекса, построенный на анализе поведения исследуемых сайтов. При обнаружении подозрительной активности страница отмечается как опасная, а вредоносный код добавляется в базу вирусных сигнатур. Данные о заражённых сайтах обновляются несколько раз в сутки.
Защита от мошеннических сайтов
Яндекс также выявляет сайты, обладающие признаками мошеннических. К ним относятся, например, страницы, созданные с целью выманить номер телефона пользователя или вынуждающие его отправить сообщение на короткий номер, потеряв деньги. В «Безопасном» и «Семейном» режимах, Яндекс.DNS блокирует такие сайты — при попытке зайти на них, пользователь увидит предупреждение.
Защита от ботнетов
Попавший в ботнет заражённый компьютер обычно управляется централизованно, через специальный C&C-сервер (от англ. command-and-control — «командование и контроль»). Адрес управляющего сервера меняется динамически, чтобы затруднить его обнаружение и блокировку. Поэтому боту на заражённом компьютере известно только доменное имя сервера — IP-адрес он запрашивает с помощью системного DNS. Яндекс.DNS в «Безопасном» и «Семейном» режимах блокирует запросы IP-адресов всех известных C&C-серверов. Из-за этого программа-бот вынуждена бездействовать, а злоумышленник теряет удалённый доступ к компьютеру пользователя. Постоянно обновляемый список ботнетов и управляющих серверов Яндекс получает от системы Virus Tracker.
Блокировка сайтов для взрослых
Алгоритмы Яндекса умеют определять эротический и порнографический контент в проиндексированных страницах. Анализируется как текст и картинки в документе, так и другие факторы — например, ссылочное окружение. Данные о сайтах с такими страницами обновляются 2-3 раза в неделю.
Блокировка рекламы для взрослых
В «Семейном» режиме Яндекс.DNS блокируется реклама эротического и порнографического характера на всех сайтах. Для хоста такой рекламной сети запрещается получение правильного IP-адреса, поэтому сами объявления и баннеры не могут быть загружены.
Яндекс.DNS в роутере
Яндекс.DNS доступен в роутерах Asus, D-Link, TP-Link и ZyXEL. Для популярных моделей этих производителей выпущены специальные версии прошивки с интегрированным Яндекс.DNS.
Особенности Яндекс.DNS в роутере:
- Возможность в один клик выставить режим по умолчанию, в том числе для вновь подключаемых устройств.
- Для каждого устройства можно выбрать свой режим Яндекс.DNS. Устройства идентифицируются по MAC-адресу.
- В «Безопасном» и «Семейном» режимах все запросы к другим DNS-сервисам обрабатывает Яндекс.DNS.
dns.yandex.ru