Пролог: Для начала я расскажу о проекте, чтобы были представления о том как мы работали над проектом и для воссоздания той боли, которую мы чувствовали.

Я как разработчик вступил в проект в 2015-2016 точно не помню, но он работал 2-3 года ранее. Проект был очень популярен в своей сфере, а именно игровых серверов. Как странно не звучало, но проекты по игровым серверам ведутся и по сей день, недавно вакансии видел и чуток поработал в одной команде. Поскольку игровые сервера строятся на уже созданной игре, следовательно для разработки используется скриптовый язык который встроен в движок игры.

Мы разрабатываем почти с нуля проект на Garry’s Mod (Gmod), важно подметить, что на момент написания статьи Гарри создает уже новый проект S&Box на движке Unreal Engine. Мы же до сих пор сидим на Source.

Который вообще не подходит для нашей тематики сервера.

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

Для сотрудников данной компании системный интегратор IBS Platformix развернул инфраструктуру виртуальных рабочих мест (Virtual Desktop Infrastructure, VDI). Ее основой стало стало аппаратное обеспечение от нескольких производителей, в том числе серверы и тонкие клиенты Lenovo.

Я понимаю, что, возможно, Апач на данный момент не является предпочтительным выбором для запуска на нём новых проектов, то тем не менее, он существует, здравствует и проекты на нём таки работают. Выбор на него может пасть по каким-то личным предпочтениям, по требованиям совместимости, или каким-то другим соображениям… не суть. В этой статье я хочу по пунктам описать, как настроить поддержку протокола HTTP/2 на веб-сервере Apache, потому что сам им пользуюсь и в такой статье нуждаюсь нуждался, и надеюсь, что кому-нибудь она тоже пригодится на практике.

В самом сердце информационно-поисковых систем Meltwater и Fairhair.ai работает набор кластеров Elasticsearch с миллиардами статей из СМИ и социальных медиа.

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

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

12 ноября Google по тихому обновил PageSpeed Insights, изменив в нем практически все. Это станет большой переменой для всей индустрии сайтостроения. Похоже, сейчас настанет некоторая волна паники и хайпа вокруг этого события. В статье — анализ перемен и что они нам принесут.

Несмотря на надежность современных центров обработки данных, для критически важных объектов необходим еще один уровень резервирования, ведь вся IT-инфраструктура может выйти из строя из-за техногенной или природной катастрофы. Для обеспечения катастрофоустойчивости приходится строить резервные ЦОДы. Под катом наш рассказ о возникающих при их объединении (DCI — Data Center Interconnection) проблемах.

Добрый день, %username%. Меня зовут Антон Резников, я работаю над проектом Облако Mail.Ru Сегодня я хочу рассказать о технологиях балансировки трафика, проиллюстрировав историей о развитии социальной сети. Все персонажи выдуманы, а совпадения почти случайны. Статья обзорная, составлена по следам доклада на Highload Junior 2017. Некоторые вещи могут показаться элементарными, но опыт проведения собеседований показывает, что это не совсем так. Кое-что будет спорным, не без этого.

Если интересно, добро пожаловать под кат.

[Прим. переводчика. Материал статьи относится к Windows Server 2003/2003R2/2008/2008R2, но большинство из описанного справедливо и для более поздних версий ОС]

Уоррен снова здесь. Эта статья — краткое справочное руководство о том, как правильно вычислить минимальный размер промежуточной папки, необходимый для нормальной работы DFSR. Задание меньших значений может привести к замедлению репликации или вообще к ее остановке. Имейте в виду, что это лишь минимальные значения. Принимая решение о размере промежуточной папки, помните следующее: чем больше будет размер промежуточной папки, тем лучше, вплоть до размера самой реплицируемой папки. За дополнительными сведениями о том, как важно использовать верный размер промежуточной папки, обратитесь к разделу «Как определить, есть ли у вас проблема с промежуточной папкой» и постам из блогов, ссылки на которые размещены в конце этой статьи.

И снова в нашей ленте «Календарь тестировщика». В этом месяце Марина Третьякова, тестировщик проекта Контур.Поставки, расскажет об оптимизации тестов. Марина разберет конкретные проблемы и способы их решения, а также посоветует, как оптимизировать свои тесты и сократить время на тестирование.

Ключевой задачей высоконагруженных WEB-систем является способность обработать большое число запросов. Решить эту проблему можно по-разному. В этой статье я предлагаю рассмотреть необычный метод оптимизации запросов к backend через технологию content-range (range). А именно — сократить их количество без потери качества системы путем эффективного кеширования.

[Прим. переводчика. Материал статьи относится к Windows Server 2003/2003R2/2008/2008R2, но большинство из описанного справедливо и для более поздних версий ОС]

Всем привет! Уоррен снова здесь, и этот пост в блоге представляет собой подборку наиболее распространенных проблем DFSR, с которыми я столкнулся за последние несколько лет. Цель этого поста — перечислить распространенные ошибки в конфигурации DFSR, из-за которых возникают эти проблемы, и уберечь вас от совершения аналогичных ошибок. Знать, чего делать не следует, так же важно, как знать, что нужно делать. Многие из описанных пунктов связаны с другими темами, поэтому для углубленного изучения вопроса предоставлены соответствующие ссылки.

Продолжаем статью, цель которой — поделиться опытом и показать ключевые особенности и частые ошибки возникающие при проектировании и организации подсистем электроснабжения ИТ-инфраструктуры и ЦОД в целом. Но хотелось бы немного расширить аудиторию и посвятить несколько разделов базовым элементам обеспечения электробезопасности и защиты оборудования и людей.

Тем, кто пропустил первую часть или хочет вспомнить первую часть можно пройти сюда.

Для тех кто понимает, что такое автомат и УЗО, для чего они необходимы, что и от чего защищают – переходите к разделу Нужны ли УЗО для IT-оборудования, серверной, ЦОДа?.

Часть вторая

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

Добрый день, друзья! Сегодня у нас будет статья, цель которой — поделиться опытом и показать ключевые особенности и частые ошибки возникающие при проектировании и организации подсистем электроснабжения ИТ-инфраструктуры и ЦОД в целом. Но хотелось бы немного расширить аудиторию и посвятить несколько разделов базовым элементам обеспечения электробезопасности и защиты оборудования и людей. Для тех кто понимает, что такое автомат и УЗО, для чего они необходимы, что и от чего защищают – переходите к разделу Нужны ли УЗО для IT-оборудования, серверной, ЦОДа? кроме того, мы разберемся в вопросе- в каких случаях перебоев в сети питания операционная система гарантированно должна работать без сбоев. Итак…

Часть первая

Осень, дождь хлещет почти непрерывно. Идет бурное строительство одного подмосковного коттеджного поселка. Комендант поселка обходя подконтрольную ему территорию видит вопиющий факт «надругательства» над временной воздушной линией 380В.

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

1. REST-интерфес;
2. WEBSocket broadcast subscription.

Метод REST зачастую используется для получения исторических данных, в то время, как по WEBSocket рассылается актуальная информация в режиме online. В некоторых случаях WEBSocket вообще не используется, а обновление происходит регулярными запросами через REST.

И вроде все довольны. Но, при более детальном рассмотрении, становится очевидными огромные накладные расходы на такую концепцию. Их основная масса ложится на REST. Для обеспечения функционирования REST-интерфейса мы должны создать backend отвечающий требованиям высоконагруженных систем. Естественно, тут можно выбирать различные варианты решения от PHP до нынче модного Golang.

Также требуется создать высокодоступную инфраструктуру, реализовать такие мелочи как CI/CD для сервисов, обеспечить все это нужными спецами по разработке, сопровождению, и т.д., и т.п.

В наши дни главным камнем преткновения на пути к высокой скорости загрузки сайтов являются изображения. Это особенно характерно для проектов из сферы электронной коммерции. На них изображения, обычно довольно «тяжёлые», составляют основную часть содержимого страниц. Это, как правило, приводит к тому, что для того, чтобы показать пользователю страницу, его браузеру требуется загрузить несколько мегабайт графических данных. Как ускорить загрузку страниц в такой ситуации? Ответу на этот вопрос и посвящён материал, перевод которого мы сегодня публикуем.

Мы начали обновлять в нашем сервисе мониторинг для PgBouncer и решили все немного причесать. Чтобы сделать всё годно, мы притянули самые известные методологии перформанс мониторинга: USE (Utilization, Saturation, Errors) Брендана Грегга и RED (Requests, Errors, Durations) от Тома Уилки.

Под катом рассказ с графиками про то, как устроен pgbouncer, какие у него есть конфигурационные ручки и как используя USE/RED выбрать правильные метрики для его мониторинга.

Автор электронной книги — Эдди Османи, один из руководителей разработки Google Chrome

tl;dr

Cжатие изображений всегда должно быть автоматизировано

Оптимизацию графики обязательно надо автоматизировать. О ней легко забыть, рекомендации меняются, да и сам контент может легко проскользнуть мимо конвейера сборки. Для автоматизации при сборке используйте imagemin или libvips. Есть и много других.

Большинство CDN (например, Akamai) и сторонних решений вроде Cloudinary, imgix, Fastly Image Optimizer, Instart Logic SmartVision и ImageOptim API предлагают комплексные автоматизированные решения для оптимизации изображений.

На чтение статей и настройку конфигурации вы потратите время, которое дороже оплаты их услуг (у Cloudinary есть бесплатный тариф). Но если всё-таки не хотите отдавать работу на аутсорсинг по соображениям стоимости или из-за дополнительной latency, то выбирайте приведённые выше варианты с открытым исходным кодом. Проекты Imageflow или Thumbor предлагают альтернативу на собственном хостинге.

До сих пор проблема накопления (аккумулирования) электроэнергии существовала без каких-либо глобальных изменений, технологического прорыва в данной области никто предложить не мог. Это был тот самый аккумулятор Гастона Планте 1859 года, доработанный различными вспомогательными технологиями и оснащенный усовершенствованиями в области электрохимических процессов, борьбы с выделением водорода, другими материалами корпуса и пр. На рубеже начала 2000 годов появились различного вида литиевые аккумуляторы, которые уверенно вытесняют во всех областях стандартные щелочные, кальциевые, AGM и гелевые аккумуляторы. В данный момент литий-ионные и литий-полимерные аккумуляторы уже завоевали рынок бытовых устройств, технология отработана и позволяет делать АКБ любой формы, ёмкости и размеров. Пришло время отработанных промышленных решений на базе литиевых аккумуляторов. Предлагаю разобраться, почему в серверных и ЦОДах за этой технологией будущее…

На заре карьеры я работал в компании, которая выпускала систему управления контентом. Эта CMS помогала отделам маркетинга самостоятельно управлять сайтами, а не полагаться на разработчиков при каждом изменении. Система помогла клиентам сократить операционные расходы, а мне — научиться создавать веб-приложения.

Хотя сам продукт имел очень общее назначение, клиенты обычно использовали его для конкретных задач. Эти задачи выжимали максимум из CMS, а разработчикам приходилось искать решение проблем. После десяти лет работы в таком окружении я узнал огромное число способов, как может сломаться веб-приложение в продакшне. Некоторые из них обсудим в этой статье.

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

Если вы начали работу в таком окружении, а затем приступили к созданию и развёртыванию веб-приложения с нуля, то очень быстро узнаете, что такое «до опасного поверхностные знания».

Сайты по-прежнему загружаются слишком медленно. В самый критический момент процесса загрузки канал зачастую практически полностью простаивает. Новая технология, предложенная инженером Кадзухо Оку из Fastly, поможет лучше использовать эту критическую первую пару секунд.

Вы когда-нибудь загружали сайт на телефоне — и смотрели в течение 10 секунд на страницу без текста? Никто не любит сидеть и глядеть на пустой экран, пока загружается какой-то необычный шрифт. Поэтому есть смысл перенести загрузку таких важных вещей на максимально раннее время. Предзагрузка Link rel=preload должна была частично решить проблему. Первым делом браузер парсит HTTP-заголовки, так что это идеальное место, чтобы указать на предварительную загрузку ресурса, который точно понадобится позже.