Серверная оптимизация *

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

Наверное, уже все слышали, что в соответствии с вступившим в силу Федеральным законом от 21 июля 2014 г. № 242-ФЗ "О внесении изменений в отдельные законодательные акты Российской Федерации в части уточнения порядка обработки персональных данных в информационно-телекоммуникационных сетях" необходимо организовать хранение и обработку персональных данных в России. Тема, конечно же, коснулась почти всех зарубежных финансовых организаций, представленных у нас в стране. Колесо завертелось и волею судьбы мы выиграли на исполнение проект одного зарубежного банка по созданию ИТ-инфраструктуры под миграцию его информационных систем (ИС) в Россию. Сорри, контракт включает NDA, поэтому назвать банк не можем. Но можем рассказать, как все это мы реализовали, какое решение предложили, архитектуру, СПД, какие вендоры – в общем, весь наш опыт передаем ниже.

Фотография пользователя Wonderlane, Flickr

NGINX великолепен! Вот только его документация по ограничению скорости обработки запросов показалась мне, как бы это сказать, несколько ограниченной. Поэтому я решил написать это руководство по ограничению скорости обработки запросов (rate-liming) и шейпингу трафика (traffic shaping) в NGINX.

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

Прежде всего, давайте договоримся: те, кому технология Intel vPro не в новинку, могут не тратить времени на всю вступительную часть статьи, сразу заказать Intel Core I7 7700 c 16 GB DDR4 240 SSD c защитой от DDOS за 3800руб в мес, без установочного платежа (ссылка в конце статьи). Но нам кажется, что пока не все оценили преимущества удалённого доступа при помощи Intel vPro – который в нашем дата-центре предоставляется ко всем выделенным серверам без серверных платформ. А значит, нужно разобраться: что это за технология такая, какая она реализовывается, и какие проблемы решает.

Что такое Intel vPro?

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

Сетевой стек Linux по умолчанию замечательно работает на десктопах. На серверах с нагрузкой чуть выше средней уже приходится разбираться как всё нужно правильно настраивать. На моей текущей работе этим приходится заниматься едва ли не в промышленных масштабах, так что без автоматизации никуда – объяснять каждому коллеге что и как устроено долго, а заставлять людей читать ≈300 страниц английского текста, перемешанного с кодом на C… Можно и нужно, но результаты будут не через час и не через день. Поэтому я попробовал накидать набор утилит для тюнинга сетевого стека и руководство по их использованию, не уходящее в специфические детали определённых задач, которое при этом остаётся достаточно компактным для того, чтобы его можно было прочитать меньше чем за час и вынести из него хоть какую-то пользу.

Исходные данные

# do a typical thumbnail, preserving aspect ratio
new_photo = photo.copy()
new_photo.thumbnail(
    (width, height),
    resample=PIL.Image.ANTIALIAS,
)
thumbfile = cStringIO.StringIO()
save_args = {'format': format}
if format == 'JPEG':
    save_args['quality'] = 85
new_photo.save(thumbfile, **save_args)

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

На этот раз рассказ пойдет про миграцию данных между двумя кластерами ElasticSearch 2.2 и 5.2.2, которая стоила немалых нервов лично мне. Как-никак, предстояло перевезти 24 миллиарда записей, не сломав уже работающую систему.

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