Почему мы не торопимся применять новые технологии

В комментариях к постам про разбор аварии (тут ^[1]и тут ^[2]) было развёрнутое обсуждение про новые технологии в ИБП, которые можно внедрить. Коротко — мы не будем внедрять ничего ультрасверхсовременного. Потому что лучшая версия для знакомства с софтом — это 2.4. В случае MS ещё хорошо, когда за цифрами написано что-то вроде SP2. Потому что если пробовать на себе все новые технологии, то это, конечно, дико интересно и прогрессивно, но мешает бизнесу. У нас дефицит свободного времени и рук. Вот, собственно, несколько прикладных историй, почему мы не торопимся нырять в новые технологии.

Пример с новым железом, на котором может строиться вся инфраструктура, думаю, знаком всем, поэтому начну не с него, а с холивара про IPv6 против IPv4.

Протокол v6 невероятно хорош. Его писали думающие люди, он снимает море проблем интернета, он реально крут. Адреса IPv6 практически бесплатные. Они не кончаются. В свою очередь, IPv4 стоят совершенно неприличных уже денег (это вторая статья в себестоимости виртуальной машины после железа), постоянно дорожают — и, что гораздо хуже, не всегда можно взять в аренду нужное их количество. Бывает, что к нам заезжает крупный клиент, мы хотим арендовать ещё 256 адресов v4 — и блок освобождается не через 15 минут, а через несколько дней. То есть нам надо постоянно ковыряться с тем, чтобы они были.

Но при этом IPv6 ещё хуже с точки зрения реального применения. Вообще, я лично не совсем понимаю, кому сейчас он нужен. Многие наши коллеги, кто пользуется, говорят просто: «В РФ v6 нет и не будет в ближайшее время, наверное». А специалисты по ИБ ещё категоричнее: «Я его просто отрубаю от греха подальше».

▍ Что не так с IPv6

Просто он при всей своей продуманности ещё не был внедрён в реальности. Если бы мы строили VDS-хостинг с нуля, то, наверное, сразу делали бы на v6. Мы когда-то начали с v4 с ощущением, что вот-вот он закончится, скоро-скоро будет уже v6, надо только подождать годик. Повторялся этот цикл восемь раз. IPv4-адреса мы не покупали, а продолжаем арендовать.

IPv6 внедряли разные наши друзья, крупные компании рядом, но есть море примеров, как крупный уважаемый хостинг ^[3] внимательно присмотрелся и не внедрил. И на это есть ряд причин. Первая — серьёзные проблемы с безопасностью. Они происходят от банального непонимания, как всё это работает. Нужно несколько лет опыта админов, чтобы научиться правильно курить этот бамбук. IPv6 очень легко сломать, особенно если плохо представляете, как с ним работать. У наших админов по 20 лет опыта сетевых технологий, но они уверенно говорят, что компетенций недостаточно. А наращивать компетенции наживую мы не готовы. Вряд ли вы хотите, чтобы на вас так экспериментировали. Поэтому ограниченные тестовые инсталляции — и постепенно учимся. Весь новый дописываемый код к хостингу ^[3] уже учитывает IPv6 несколько лет подряд, но переключаться мы всё ещё не готовы по причинам ИБ. Это основной вопрос.

Второй вопрос, который в принципе решаем, но задорого — это блокировки по IP от РКН. Если вы посмотрите на список компаний, поддерживающих IPv6 в России ^[4], то можете не увидеть знакомых лиц. А те, кто заявил о поддержке, часто размещают плашку «тестовый режим» на сайте. Потому что у них тоже есть ИБ и отношения с РКН.

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

Переход на v6 — это тоже деньги. Нужно будет менять или докупать железо (потому что будут новые требования к производительности), нужно будет переписывать софт, строить мосты между сетями, настраивать кучу прослоек для трансляции адресов и трафика. И это всё узлы, где возможны отказы и уязвимости. Это всё заставляет очень тщательно смотреть, что мы за это получим против того, что можем потерять. И ещё мне кажется, что реальный запрос на v6 — низкий. Практически всем нужны именно публичные IPv4-адреса в первую очередь, чтобы DNS работали нормально. Топовые современные DNS хорошо работают с любой адресацией, но не все топовые.

Что удивительно, по мере роста проникновения v6 IPv4-адреса не упали в цене — и дефицит до сих пор есть. Они всем нужны. Сохраняется очень много старого сетевого железа на всех уровнях — ЦОДы, операторы связи, любые сети. Где инфраструктура появилась не вчера, есть старое железо и старый софт. Мотивы похожи у всех игроков: есть сложившийся бизнес, нет срочности в переходе. Ещё пример: всем имеющимся клиентам нужно будет заново настраивать свою собственную защиту, потому что переход на v6 означает другой принцип фильтрации трафика. Либо нам надо будет придумывать новые ноу-хау по этой фильтрации на уровне ЦОДа. На текущий момент мы решили три суперкрупных проблемы успешно — на IPv6 их же надо будет решать заново. Но решать по-другому из-за другого устройства протокола. Спуфинг роутера, спуфинг адресов — там всё иначе будет. Протоколы маршрутизации другие. Назначение адресов другое. Отличия фундаментальные. Если их решить не полностью, клиенты столкнутся с проблемами. Это ключевой стоп-фактор для прогресса: если есть клиенты — тяжело внедрять новое.

Но, как я говорил, если бы мы делали с нуля, то, конечно, начали бы именно с IPv6.

Поэтому наш путь — медленная эволюция в эту сторону без спешки. Как и с другими новыми технологиями.

▍ Железо

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

Мы внедряем гомогенное корпоративное железо. Самое мощное на рынке, как правило (да и б/у достать просто не выйдет, вендор обычно быстро вытесняет линейку новой коллекцией, как в моде). Например, когда «Huawei» выводил из производства диски, мы покупали-покупали, потом раз — они меняют партию. Старая коллекция уничтожается, новая завозится — как в лучших модных домах. Понятно, что это у дистрибьюторов, на вторичном рынке можно достать хоть перфокарты. Но в общем случае — у вас одна линейка железа, вы покупаете и обслуживаете её. А чем меньше зоопарк, тем легче он поддерживается в ЦОДах по миру по софту и по ЗИПу.

▍ Эпопея с NVMe

Железо же можно внедрять не только по критерию надёжности, но и по критерию новизны. Например, есть NVMe-диски, которые в какой-то момент стали модными на рынке VDS-хостинга. У нас с этим целая эпопея ^[5]. Коротко — либо все врали, либо мы чего-то системно не понимали в технологии. Оказалось, следующее:

• Да, многие врут и ставят обычный SSD под видом NVMe. Простите, но тут пруфов не будет, это мои фантазии.
• Факт: рейды на NVMe делать бесполезно, они замедляют обращения, по сути. То есть никакой надёжности дисков от случайного вылета в любой момент. Только бекапы.
• Факт: мы стали прикручивать к серверу HDD для автобекапов NVMe один или два раза в сутки. Клиенты их не видят, но это слой защиты, который важен.

Смысл технологии был в скорости. Если технология после тестов этот желаемый результат не показывает, надо либо продолжать тесты, либо не внедрять. Потому что, если задача не решается, нет смысла подписываться на что-то на несколько лет вперёд в куче ЦОДов просто потому, что это модное маркетинговое слово. Мы внедряли очень долго, пока не получили хорошие характеристики. Потому что у нас нет своего конструкторского бюро, у нас нет нон-стоп сборки, у нас есть наши админы, которые решают ещё сотни задач. Они парт-тайм собирают железо и гоняют его как умеют. Мы уже спутники запускать научились, скоро пара выйдет на орбиту — а с NVMe провозились куда дольше. Даже спалили одного конкурента (и не только мы спалили ^[6]), который использует не сами NVMe-диски, а HDD с NVMe-кешем. Но у нас задача — чтобы это работало практически. А для этого надо понять, какое железо лучше купить, какой производитель, какие характеристики.

Тут же возникает вопрос: у кого на рекламе написано «у нас только NVMe» — куда делись другие диски? Взяли всё выкинули? Правда? А если тесты скорости запустить?

Дальше сами диски. С теми же SSD мы очень заморочились с надёжностью в своё время, очень долго тестировали классику рейдов. Дело в том, что диски в массиве выходят из строя плюс-минус в одинаковое время. И если один посыпался, то второй может вылететь прямо во время ребилда. Если нет допбекапа, то вы потеряли массив данных. Потом надо объяснять клиенту, что случилось. Вот недавно пользователь ^[7] приходил в соседний пост, у него была как раз такая ситуация. Дело в том, что примерно на 10% серверов у нас нет дополнительного HDD для бекапа рейдов. На всех уже почти есть, но на самом первом поколении, пока мы недооценивали про эту фичу SSD, — нет. Мы постепенно выводим такие серверы из работы, но вот одному отдельно взятому человеку не повезло.

Эта же система означает, что у вас должен быть построен мониторинг на мониторинге. Предположим, купили вы хорошие SSD, собрали их в правильные рейды, поставили мониторинг их состояния, настроили бекап. Дальше надо мониторить мониторинг — а отдаёт ли он вообще данные или собирает туфту. А работает ли бекап? А правильно ли он записывается? А разворачивается ли вообще? В какой-то момент после третьего мониторинга на мониторинг мы внезапно узнали, что воюем вообще не в ту сторону. Мы-то из финансов, для нас потеря транзакции — уже очень печальное событие. Но большинству наших клиентов нужны были не данные, а быстрое продолжение работы. Поэтому вместо «пытаемся вытащить данные с сервера и через четыре часа мучительной работы админа подключаем его в прежнем виде» и «даём такой же сервер и потом когда-нибудь подмонтируем диск с восстановленными данными» — в этой ситуации клиенту намного приятнее второе. По опыту потери данных — а таких случаев в хостинге ^[3] за годы было несколько — люди просят пустую виртуалку. Для них SLA по непрерывности важнее сохранения данных.

В общем, просто помните, что любой сервис делают раздолбаи. Мы тоже раздолбаи. Разница в том, насколько раздолбаи понимают своё несовершенство и строят меры, защищающие от проблем.

▍ Почему нет последней версии Win

Потому что мы ну вот уж не настолько раздолбаи )

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

Принципы такие:

• Критичные обновления безопасности (вроде как после хартблида) устанавливаются практически мгновенно в образы и очень оперативно на запущенные клиентские машины с предупреждением о простое.
• Новые версии ОС и сервис-паки сначала проверяются на адекватность, потом идут в прод. В 2015-м вышла 16-я серверная винда, мы обновили её образы, и выяснилось, что она не совсем прямая, не совсем стабильная и не совсем хорошо совместима с кое-чем из сетевых драйверов. Итог — постоянные перезагрузки. Пока разбирали инциденты, даже не думали, что они связаны с ОС, но потом внезапно поняли, что жалуются только те, кто получил новый образ. Что ещё хуже, надо было останавливать других клиентов на передеплой сервера, объявляя техработы.

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

На всякий уточню, что новую ОС надо тестировать не только на совместимость с гипервизором и прочим, не только в вакууме на стабильность, но и на конкретной инфраструктуре. Например, если в сетевом драйвере после пары патчей и оптимизаций вдруг будет сдвинут приоритет операций R/W, то вас может ждать какой-нибудь довольно забавный сюрприз позже.

▍ Почему бы не сделать новый хостинг только на новых технологиях?

Конечно, нам бы хотелось. Взять IPv6, только NVMe, поставить свежую винду и *nix из нестабильной сборки, купить десктопное железо и самортизировать его — ээээх, вот это был бы хостинг ^[3] с мощным маркетингом! Правда, через год пришлось бы переобуваться, но это был бы весёлый год.

Проблема в команде. Если есть два проекта, то нужны две команды — иначе одна будет делать тот проект, который больше нравится, а второй будет жить по остаточному принципу. Две независимые команды — это космос, это дорого и сложно. В первую очередь речь про компетенции админов и разработчиков, во вторую — про маркетинг. С маркетингом всё стало сложнее, и новый проект с нуля делать будет тяжко. Рынок стал намного более конкурентным, чем когда мы начинали. Чтобы хостинг ^[3] покупали, надо быть в топе поиска, Хабра (хотя это не про покупки, а про бренд) и так далее. Наш продукт — это в том числе маркетинг, в который вложено много сил и эмоций, на потоке это повторить не выйдет.

Выиграй телескоп и другие призы в космическом квизе от RUVDS. Поехали? 🚀 ^[8]