Новый способ охлаждения дата-центра от Microsoft

Погрузить компьютер под воду (не пытайтесь воспроизвести в реальной жизни — так бы гласила бегущая строка в рекламе). Но вот мировому гиганту Microsoft данное действие показалось отличнейшей идеей. Ведь известно, что на запитку систем охлаждения серверов затрачивается немалое количество электроэнергии, которая не так уж и дешево стоит. Почти половина от общего энергопотребления серверной фермы уходит на охладительные устройства (кондиционеры, чиллеры и т.д.). Поэтому многие компании уже давно в поисках новых эффективных методов охлаждения для своих «детищ». Не так давно, а если быть точными, то в августе 2015 года компания Microsoft решила сьекономить на оплате счетов за электроэнергию, погрузив экспериментальный прототип нового подводного дата-центра на морское дно. Так родился прототип ЦОД под кодовым названием Leona Philpot соответственно проекту Natick.

Ранее мы рассматривали различные нюансы собеседования ИТ-специалистов и управленческие кейсы, связанные с работой технологических компаний. Сегодня мы поговорим о том, как правильно критиковать своих сотрудников.

В NGINX версии 1.9.1 появилась новая возможность, позволяющая использовать сокетную опцию SO_REUSEPORT, которая доступна в современных версиях операционных систем, таких как DragonFly BSD и Linux (ядра 3.9 и новее). Данная опция разрешает открывать сразу несколько слушающих сокетов на одном и том же адресе и порту. При этом, ядро будет распределять входящие соединения между ними.

Наконец-то у нас появились видео выступления наших спикеров на Highload 2015, которые мы с удовольствием выкладываем.

Если у вас появятся вопросы к докладчикам, задавайте их в комментариях. Ребята на них обязательно ответят.

1. «Near-realtime аналитика событий в высоконагруженном проекте», доклад Александра Крашенинникова

Perl долгое время ничего не знал про кодировки. Строка была просто последовательностью байтов, каждый держал там все что хотел, и лишь изредка приходилось задумываться о том, какая же все-таки кодировка у этих данных. Времена изменились, появился UTF; поддержать его пришлось и перлистам. Как это обычно бывает, in a perl way. Я надеюсь, что эта статья сбережет немного здоровья тем, кто до сих пор пребывает в неведении относительно реализации UTF-8 в Perl.

Доброго времени суток, уважаемые хабравчане! В Elasticweb мы негласно ратуем за Nginx и, наверное, мы одни из немногих хостингов, которые не поддерживают Apache и .htaccess соответственно. В связи с этим, большое количество обращений в тех. поддержку связано с оказанием помощи в написании конфигурационного файла для Nginx. Поэтому мы решили собрать коллекцию полезных сниппетов и коллекцию готовых Nging конфигов для наиболее популярных CMS/CMF/Фреймворков на PHP.

NGINX вполне заслуженно является одним из лучших по производительности серверов, и всё это благодаря его внутреннему устройству. В то время, как многие веб-серверы и серверы приложений используют простую многопоточную модель, NGINX выделяется из общей массы своей нетривиальной событийной архитектурой, которая позволяет ему с легкостью масштабироваться до сотен тысяч параллельных соединений.

Инфографика Inside NGINX сверху вниз проведет вас по азам устройства процессов к иллюстрации того, как NGINX обрабатывает множество соединений в одном процессе. Данная статья рассмотрит всё это чуть более детально.

Знаете анекдот про самолет, в котором есть и бар, и бассейн, и ресторан, но только при взлете стюардесса говорит: «А теперь со всем этим мы попробуем взлететь»?

Веб-разработка немного похожа на такой самолет. Заказчик хочет от веб-студии и классный дизайн, и кучу интерактива, и все службы доставки и оплаты в интернет-магазины, студия с удовольствием все это программирует… А вот хватит ли мощностей сервера на обеспечение стабильной работы сайта — непонятно.
Чтобы нагрузка была прогнозируемой, чтобы задать некоторые эталонные значения, мы провели нагрузочное тестирование «1С-Битрикс: Управление сайтом» и «1С-Битрикс: Энтерпрайз».

Мы постарались так провести тестирование, чтобы клиент понимал, что можно получить на текущем оборудовании, а разработчик мог понять, каковы перспективы роста проекта. Получится ли отмасштабироваться при росте нагрузки?

В этой статье мы расскажем о том, как организовывали и проводили тестирование, и какие выводы для себя сделали.

Для чего это может быть полезно? Эталонные цифры дадут возможность сравнить текущую площадку с потенциальным новым хостингом, четко оценить, какой эффект оказывает на систему внедрение новой функциональности. Да и просто понять технические пределы системы.

Мы сделали акцент на вопросах организации тестирования, на специфических проблемах, с которыми столкнулись в процессе тестирования и на том, какие выводы можно сделать по результатам тестов. Для самых заинтересованных — вот ссылка на подробный технический отчет.

До недавнего времени в Одноклассниках в качестве основного Linux-дистрибутива использовался частично обновлённый OpenSuSE 10.2. Однако, поддерживать его становилось всё труднее, поэтому с прошлого года мы перешли к активной миграции на CentOS 7. На подготовительном этапе перехода для CentOS были отработаны все внутренние процедуры, подготовлены конфиги и политики настройки (мы используем CFEngine). Поэтому сейчас во многих случаях миграция с одного дистрибутива на другой заключается в установке ОС через kickstart и развёртывании приложения с помощью системы деплоя нашей разработки — всё остальное осуществляется без участия человека. Так происходит во многих случаях, хотя и не во всех.

Но с самыми большими проблемами мы столкнулись при миграции серверов раздачи видео. На их решение у нас ушло полгода.

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

Сегодня утром ряд клиентов, поддержку веб-серверов которых я осуществляю, получили письма счастья о смене ДНС серверов:

Домен:

domain: *******.RU
admin-o: *******-GPT
* nserver: ns-*******.awsdns-34.org
* nserver: ns-*******.awsdns-58.com
* nserver: ns-*******.awsdns-12.net
* nserver: ns-*******.awsdns-30.co.uk
state: REGISTERED, DELEGATED
created: 29-11-2011
changed: 30-08-2015
paid-till: 29-11-2015
mnt: TIMEWEB-MNT-GPT
source: R01

заменен на:

domain: *******.RU
admin-o: *******-GPT
* nserver: ns1.hostingnewfree.ru
* nserver: ns2.hostingnewfree.ru
state: REGISTERED, DELEGATED
created: 29-11-2011
changed: 30-08-2015
paid-till: 29-11-2015
mnt: TIMEWEB-MNT-GPT
source: R01

Сверка с whois действительно подтвердила серьезность данного письма, везде фигурировали одинаковые днс, а то, что на данную проблему жаловались несколько клиентов одновременно, заставило попробовать разобраться с проблемой глобально, не занимаясь изучением взлома одного клиента.

Есть сервисы, защищающие нас от DDoS атак. Они работают по принципу прокси: в DNS прописывается их IP, они фильтруют трафик и проксируют на ваш сервер. Все они настоятельно рекомендуют прятать свой IP и в публичном доступе давать только IP прокси-защитника. Вполне здравый подход, достаточный для успешной защиты. А я расскажу на чем можно проколоться и как от этого защитится.

Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!

Это краткая заметка как настроить отказоустойчевый кластер с балансировкой нагрузки из 2 MySQL серверов. Исходные данные 2 свежеустановленных MySQL сервера. Необходимо настроить работу таким образом, что бы в нормальной ситуации запросы балансируются между MySQL серверами, в случае выхода из строя одного из MySQL серверов все запросы идут ко второму.

В стремлении к быстрому сайту многие разработчики упускают один важный момент: клиентскую (фронтендную) точку отказа (frontend SPOF – single point of failure). Причем, почти все инструменты тестирования скорости загрузки сайта также не выявят потенциальных проблем.

В конце июня в Москве прошла конференция Bitrix Summer Fest, на которой было представлено много интересных и полезных докладов. Чтобы этот кладезь мудрости не пропадал, мы будем публиковать в нашем блоге материалы по выступлениям с конференции. И начать мы решили с доклада Антона Герасимюка, посвящённого оптимизации скорости загрузки страниц.

21 апреля Google поменял алгоритм ранжирования поисковой выдачи для мобильных устройств. Многие владельцы сайтов и администраторы получили письма, в которых сообщалось, что «ваш сайт не оптимизирован под мобильные устройства». И после 21 апреля на всех сайтах, которые перестали удовлетворять новым критериями, стал падать поисковый трафик с Google.

Точка встречи сотового оператора с роуминговыми и домашними абонентами

В России 6 узловых аэропортов выделяются на фоне остальных. Долгие годы эта шестёрка преобладает в рейтинге самых загруженных аэропортов нашей страны. Большая часть авиаперевозок пассажиров приходится именно на них. Они концентрируют в себе порядка 70% общего трафика пассажиропотока. Это: Домодедово (33,04 млн. пас. в год), Шереметьево (31,57 млн. пас. в год), Пулково (14,26 млн. пас. в год), Внуково (12,73 млн. пас. в год), Кольцово (4,53 млн. пас. в год) и Толмачёво (3,96 млн. пас. в год).


Географическое расположение крупнейших аэропортов России

В этих узловых аэропортах мы провели модернизацию мобильной сети. Я отвечал за техническую и информационную части этого проекта.

Как известно, для обработки соединений NGINX использует асинхронный событийный подход. Вместо того, чтобы выделять на каждый запрос отдельный поток или процесс (как это делают серверы с традиционной архитектурой), NGINX мультиплексирует обработку множества соединений и запросов в одном рабочем процессе. Для этого применяются сокеты в неблокирующем режиме и такие эффективные методы работы с событиями, как epoll и kqueue.

За счет малого и постоянного количества полновесных потоков обработки (обычно по одному на ядро) достигается экономия памяти, а также ресурсов процессора на переключении контекстов. Все преимущества данного подхода вы можете хорошо наблюдать на примере самого NGINX, который способен обрабатывать миллионы запросов одновременно и хорошо масштабироваться.

Каждый процесс расходует память и каждое переключение между ними требует дополнительных циклов процессора, а также приводит к вымыванию L-кэшей

У медали есть и обратная сторона. Главной проблемой асинхронного подхода, а лучше даже сказать «врагом» — являются блокирующие операции. И, к сожалению, многие авторы сторонних модулей, не понимая принципов функционирования NGINX, пытаются выполнять блокирующие операции в своих модулях. Такие операции способны полностью убить производительность NGINX и их следует избегать любой ценой.

Но даже в текущей реализации NGINX не всегда возможно избежать блокировок. И для решения данной проблемы в NGINX версии 1.7.11 был представлен новый механизм «пулов потоков». Что это такое и как его применять разберем далее, а для начала познакомимся с нашим врагом в лицо.

В среде веб-разработчиков все больше распространяется знание о том, что скорость важна. Многие стараются ускориться: используют сжатие gzip, минификацию, кеширующие заголовки, сокращение запросов, оптимизацию картинок и другие.

После выполнения этих рекомендаций возникает вопрос: а что именно мы оптимизируем? Оказывается, что в большинстве случаев это время полной загрузки страницы со всеми элементами. Однако, это не совсем то, что нужно. На самом деле важно время, за которое пользователь получает «первый экран» страницы с важными функциональными элементами (заголовок, текст, описание товара и т.д.) Другими словами, важен момент начала рендеринга страницы. Здесь и возникает критический путь рендеринга, который определяет все действия, которые должен выполнить браузер для начала отрисовки страницы. С этой штукой мы и будем разбираться в статье.