Серверы

Вот приходишь на смену, а дорогие коллеги, большие профессионалы, сломали IP-KVM. Ну то есть совсем сломали, выдернут из текстолита VGA-разъем видеовхода, уронили наверное. KVMпоследний и единственный, остальные уехали в другой ДЦ на международный проект, а это значит, что при любом заказе на трешовый дедик уровня core2duo придется переть из теплого офиса по улице 500 метров в модуль и сидеть там от 15 минут до часу времени, накатывая ручками всю хурму на серваки локально. В модуле холодно и шумно, и вайфай медленный, что же делать?

Надо применить инженерный подход. VGA не пашет, но команды клавиатуры с KVM на сервак передаются ок. В зипе находится длинный-предлинный vga-кабель, метров тридцать в бухте. Вешаем KVM на сервак, подключаем к серваку по VGA монитор, монитор ставим на коробку, коробку на стул, стул на стол, усиливаем все скотчем подкатываем получившуюся башенку к cctv-камере в углу комнаты, ориентируя монитором прямо в объектив. Вуаля - картинка с монитора доступна по сети, команды с клавиатуры передаются по сети тоже, пусть и по другому каналу.

Довольный собой, запускаю с pxe раскатываться на серваке образ и топаю в теплый офис, чтобы по возвращению заглянуть в cctv-монитор, а там сервер в процессе сетапа свалился в kernel panic и не отвечает на клавиатуру, окей.

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

И вот, гипервизор установлен, развернуты несколько виртуалок, пока в тестовом режиме, полёт нормальный… Но вдруг сервер неожиданно падает.

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

Часа через 3 сервер выключился вновь. Поскольку время было позднее, я решил отложить дальнейшее разбирательство до завтра, благо платформа была на стадии внедрения, и никаких критичных сервисов на ней пока не было. Я грешил на перегрев процессоров, а также на память FB-DIMM, о капризах и перегревах которой был наслышан.

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

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

Тут стоит сделать уточнение. Я работаю в достаточно большой компании, в которой есть много it-отделов, занимающихся не пересекающимися направлениями. А тот небольшой дата-центр, о котором идет речь, компания арендует практически полностью. И доступ сотрудников на его территорию контролируется крайне слабо.

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

Из бонусов всей этой ситуации для меня – то, что сервер был тщательно вычищен от пыли перед предполагаемой отправкой в филиал.

Расскажу вам ещё одну историю про вежливые железки.

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

Предыстория. Так получилось, что в паре устройств нельзя было развернуть поток горячего воздуха, пришлось дуть прямо в холодный коридор. Как назло — места в стойке в обрез, пришлось прямо под пару таких горячих американских парней поставить пару серверов. Горячим воздухом им задувало прямо во входные дырки, нагревали воздух до 40 градусов, управлялки исправно ругались, но что делать? Как-то жили. Рано или поздно всему приходит конец, и управлялки по достижении пороговой температуры стали перегружать этих два сервера прямо посреди дня… В общем, выкрутились, воткнули дополнительные вентиляторы, трубами, гнутыми листами отвели поток горячего воздуха и вздохнули спокойно. Ровно на полгода.

Наступила осень. Температура воздуха упала, все стали забывать уже, что такое было. И тут бац — перегрузился сервер. Ну, думаю, остановились вентиляторы, трубы забились, младшие админчики чё-то сдвинули, будем смотреть. Да нет, те два, которые летом перезагружались — вполне себя сносно чувствуют, температура на входе далека от предельной, жить можно. Начал перегружаться сервер в соседней, полупустой стойке, сверху и снизу от которого места — завались! Мало того, серверам снизу и сверху — даже холодно! Смотрим температуру, да, высоко, два градуса вверх и перегрузимся, но терпим. Только отвернулся — бац, опять в перезагрузку.

Ну, делать нечего, пишем в саппорт, мол, подойдите, посмотрите, что там, никто телогрейку на стойку не повесил (бывали, знаете ли, случаи)? Сервер перегружается ещё раз. Лезем ещё раз смотреть, а сколько теперь-то? Увиденное повергло в шок — 25 градусов на входе. Как не бывало жары, визга мониторилки. Кого-то он там сдул, прокашлялся. Надо ли говорить — больше никаких проблем не было. Добежавшие до стойки с тепловизором наперевес инженеры, естественно, ничего не нашли, мол, отлично всё.

Так и живём. Что это было — так и не выяснили. «Я устала, я капризничаю», восстание машин и т. п.

Есть у меня домашний сервер, как, наверное, у многих айтишников: файлохранилище, прокси, VPN, DLNA, управление 1-Wire и так далее.

В качестве него используется старый нетбук с линуксом. Почему нетбук — потому что маленький и не шумит, в нём вообще вентиляторов нет. Почему не перепрошитый роутер или какой-нибудь Raspberry Pi — потому что не хотелось возиться с поиском прошивок, кросскомпиляцией и прочими интересными вещами.

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

А вот чтобы потом его включить, надо взять табуретку, подойти к стенке, долезть до него, открыть крышку, нажать кнопку (потому что настройки «включаться автоматически» в нём нет), закрыть крышку, убрать табуретку. Казалось бы, мелочь, но задалбывает, тем более что он управляет разными другими вещами, поэтому включается одним из первых, как только дали свет.

И вот, наконец, нашлось решение: конденсатор!

Ведь что такое «нажать на кнопку»? Это на пару секунд замкнуть два контакта, чтобы компьютер запустился, а потом контакты разомкнуть, чтобы он не выключился.

А что такое конденсатор? В момент подачи напряжения через него проходит ток заряда, который постепенно снижается до нуля. Чем не нажатие на кнопку?

Подходящий конденсатор на 100 мкФ нашёлся в валяющемся без дела старом CD-приводе, который всё было лень выбросить. Припаиваем его параллельно кнопке — и всё: в момент подачи напряжения нетбук сам запускается, потом конденсатор заряжается и «отпускает кнопку». Причём даже не нарушается всё остальное — настоящая кнопка-то работает, можно нажать, и он выключится, как и положено.

Просто вовремя вспомнился график заряда из учебника. А ведь уже собирался рыть интернет в поисках нового биоса для этой давно снятой с производства модели — и вряд ли бы нашёл.

А вот был у меня случай, тогда я ещё проходил промежуточную сертификацию CCNA и, естественно, хотел получить чутка практики. Созвонился со старым другом-админом, который работал на выезде и обслуживал несколько компаний. Он дал добро. И вот я, молодой шестнадцатилетний парнишка, иду со своей старенькой тошибой 2004 года на выезд. Приезжаем в компанию. Задача — файлы с сервера копирнуть на винт для безопасности, ибо сервак будет меняться, а там мало ли что, обновить небольшой парк и помочь бухгалтерам с их некой сложной проблемой.

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

— Где ваша проблема? Я её решу!

Две девочки и одна старая, но прошаренная главная объясняют суть:

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

— Не вопрос. Можно. Где секретарь?

Захожу в кабинет к секретарю. Падаю за комп, и тут меня начинает пробирать дикий хохот. За дверью начальник, еле сдерживаюсь. Оказывается, они работали терминально на серваке, всегда. Все файлы на серваке. ОС на компах стоит, но основное рабочее пространство на сервере. То есть они всегда работали в одном и том же файле, правили его все вместе и «всё у всех было». Но вопрос возник только сейчас, когда бухи уходят в отпуск.

Закончилось всё тем, что я пояснил им, что к чему. Удивление на их лицах было не передать словами. Мне же весёлое настроение было обеспечено надолго.

А «папочка с ручкой» стало для меня нарицательным выражением при создании шары.

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

Зная, как долго у нас делаются такие вещи, я забыл об этом где-то на четыре месяца, пока в один прекрасный день этот же начальник не прибежал и не сказал, что ни он, ни все его подчинённые не могут зайти на удалёнку и работать. Когда я выругался, что предупреждал про охлаждение и опасность его отсутствия, он выдал: «Так, б%#ть, сделали на следующий день после нашего разговора!» (к слову, разговаривали мы в обед в пятницу).

Когда я зашёл в серверную, где не был ни разу за четыре месяца, потому что всё отлично шуршало, последний месяц я провёл в больничке, а плановая проверка бывает только раз в полгода (не моя идея), мои глаза увидели боль — равшаны, ставившие кондёр, не только не выносили серваки, они даже не додумались их накрыть. Бедные железные монстры были покрыты многосантиметровым слоем бетонно-кирпичной массы из пыли и непонятно чего ещё. Проработав целых три месяца они всё-таки сдохли, причём все разом.

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

Я всё восстановил за два дня — всё продул и прочистил, несколько куллеров сменил. Но, что самое главное, плановая проверка теперь раз в две недели.

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

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

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

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

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

Почему система контроля версий, а не банальный бэкап? А это на другой случай, если после очередной доработки всё сломается, чтобы можно было не только откатиться к предыдущей версии, но и увидеть, что, собственно говоря, было причиной.

А любителям вносить правки в работающую систему — большой и пламенный привет!

Устроился в небольшую компанию программистом. Компания предоставляет некоторые услуги своим клиентам. Но предоставляет крайне фигово: больше полусотни пользователей не держит.

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

— Ну, у нас же реализована архитектура «запрос — ответ»! Нам же не надо держать TCP-сессию! — говорит программист с 25-летним стажем.

— Гм, — говорю я и лезу в код сервера.

Лучше бы я этого не видел.

На каждый входящий пакет создаётся поток-обработчик, который умирает сразу же после того, как отсылает пакет обратно. И, естественно, убирает за собой все данные о клиенте. Что характерно, поток-получатель парсит HTTP-заголовок.

Начинаю переписывать код. Сперва создаю пул потоков-обработчиков, но очень быстро утыкаюсь в ситуацию, когда у меня 100500 потоков на 24-ядерной системе. В общем, ситуацию это спасает, но не намного.

Далее избавляюсь от авторизации: клиенту передаётся его сессионный ID, и уже дальше работаем с ним.

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

Потом делаю ещё одну страшную вещь: переношу очередь запросов как можно ближе к получению пакетов, до парсинга HTTP-заголовка. Результат — восьмиядерный рабочий комп выдерживает стрессовую нагрузку до 100  тысяч пакетов в секунду.

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

Испытываете трудности при отдачи контента порциями? Дискомфорт, говорите? Поделюсь своим опытом раздачи терабайтов обновлений к игровым клиентам. Не знаю, как это у «танчиков», но принцип одинаков везде.

Вот вы зарелизили игру. Первый вопрос: как выкладывать? Одним большим куском или в развёрнутом виде? Тут вопросов не возникает — конечно же, большим куском, раскидать его по серверам поближе к клиентам, на площадки с доступом к основным магистралам. А вот небольшие патчи? Выкладывать сразу или творить кумулятивные обновления? Всего-то из изменений — брутального орка кто-то из локализаторов обозвал «МойЗайчик». Первая мысль была именно такая: давайте сбацаем торрент, и пущай клиенты с клиентов обновляются, меньше нагрузки на сервера, ведь при более-менее массовом апдейте нагрузка может подскочить на порядок, никаких «теньге» (10 Gigabit Ethernet) не хватит. Сделали. Водрузили Transmission на сервера — мол, обновляйтесь. Ой, что это? Почему скорость такая маленькая? А что это клиенты предпочитают качать с центра, а не с других клиентов? А неблагодарные клиенты, скачав обнову, тут же вырубают обновлятор, чтобы играть не мешал, из-за чего начинают выигрывать HTTP-пиры. Вот это и есть традиционные грабельки: гладко было на бумаге, да забыли про овраги…

Так и живём. Имеем кучу nginx, которые раздают или с общего стораджа, или по свистку синхронизируются сами. А найти сервер, который вдруг не поддерживает докачку, надо сильно постараться. Или на коленке самому написать. Nginx в том числе и для этого был создан, чтобы, не сильно потребляя ресурсы, мог отдавать кучу мелких файлов очень большому числу клиентов.

А теперь представьте, когда вы такое количество файлов обновили только наполовину. Да, проверяем целостность клиента, проверяем тысячи хешей, перекачиваем старые файлы. В результате какая-нибудь «ферма» убивает батарею недобука, когда хозяин сидит в «Макдональдсе» и пытается обновляться там. А ему ещё и каждые полчаса линк отключают: мол, переавторизоваться бы …

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