Подозреваю, что довольно значимая часть читателей поста младше, чем эти операционные системы. Но на них в закромах Родины ещё бегает наш российский (и не только) софт. Да и вы наверняка нет-нет, да видели DOS-приклад на рабочих местах Сбербанка или в больницах.
Есть такие Power-машины, которые предназначены для расчётов больших и тяжёлых штук. На них работает приклад, который не может быть запущен в обычном кластере, как правило — банковские системы и всякие биржевые штуки. Проблема в том, что современные гипервизоры создают виртуальную машину не больше, чем физический сервер, где они стоят. А один физический x86-сервер для таких задач мелковат. Поэтому и используется архитектура x64 (RISC).
Одинаковые по суммарной производительности системы на x86 и x64 отличаются по цене в десятки и сотни раз. Казалось бы, никаких проблем: надо переписать софт так, чтобы он мог работать в сотни потоков и встать в кластер или облако, да?
Ага, сейчас! Программистов, кто это писал, уже нет. Исходники обычно утеряны или же написаны на языках времён мезозоя. Даже документации обычно нет. Поэтому знаете, что мы делаем? Мы заворачиваем гипервизор в гипервизор. О, это отдельная песня. Сейчас расскажу.
Куски мамонта
Да, чёрт побери, заворачиваем гипервизор в гипервизор. Типичная задача — нужно отмигрировать что-то на тот же Huawei х86. Вообще, коммерческих архитектур, которые позволяют получать реально очень большие кластеры, хорошо подходящие для таких задач, всего три — это Супердом, кластер Фуджитсу и кластер Huawei. Отдельно есть ещё решения, но у этих трёх архитектуры похожи и близки к оптимальным по масштабированию. В нашем случае Huawei оказался выбран под проект по двум причинам:
— Цена при заданной стабильности.
— Совместимость со старыми ОС на уровне драйверов и т. п., то есть возможность миграции.
Со старыми — это значит прошлого года выпуска. Но команда разработки железа сейчас продолжает гонять тесты и добавляет совместимость со всё более и более старыми ОС, которые ещё используются в банках и промышленности по всему миру.
На очереди на тестовые внедрения Huawei стоят два крупных заказчика, поэтому тема очень горячая.
Теперь диспозиция. У заказчиков инфраструктура устоялась, баги пойманы, совместимость достигнута, поэтому действует главное правило разработчика: «работает — не трогай». В банках оно ох как важно. Взять и проапдейтиться на новую версию — это квест длиной в миллион страданий.
При этом обратите внимание это не значит, что они не переносят ничего. Те же базы с AIX’а P-серии на Linux x86 они очень быстро переделывают и накатывают — это уже отработанная процедура во многих банках.
Боль в прикладе и СУБД. Не всегда внешние NIX’ы могут работать с СУБД из-за отличия хранимых процедур и кучи других проблем совместимости. Как следствие, начинается допиливание до консистентного состояния. Если RISC-машины уже давно в этом плане устоялись, то разработчики кластеров х86 в сфере новички, и наступили ещё не на все грабли. Главное — не поддерживают фичи глубоко старого NIX, а в банках или промышленности иногда стоят совсем старые версии.
И именно в этот момент мы начинаем заворачивать гипервизор в гипервизор, Джонни! Не всегда, конечно, а только тогда, когда принимается решение, что конкретно этот приклад лучше не трогать, а то все помрут. Выглядит это так:
- Находим последнюю стабильную версию ОС, где работает приклад. Чтобы вы понимали всю боль — иногда это Novell Netware 4.x. Это где основной сетевой протокол — IPX/SPX, а TCP/IP рассматривается как фантазия из будущего, но на всякий случай поддерживается. В одном банке это чудо до сих пор работает с данными архивов. И иногда она реально нужна для глубокого поиска по финансовым данным.
- Находим гипервизор, который поддерживает эту стабильную версию ОС и приклад. Запускаем в нём. Получается, например, некий старый Linux.
- Находим гипервизор (скорее всего, уже свежую Вмвару), который поддерживает этот старый Linux. Запускаем ВМ с ВМ на нём.
Получается дом, который построил Джек.
Понятное дело, приклад от этого страдает по производительности, но деваться особо некуда. Знаю одну историю о попытке ухода с Нетвары. Лет 10 как разработчиков просто нет. Все хваленые виртуализаторы не поддерживают никак и никогда. В итоге кое-как умудрились подняться с 4 на 6,5 потом её уже в гипервизоре.
Кстати, если вы думаете, что это всё очень редкие случаи, присмотритесь к принтерам в отделениях банков, где вы бываете. Есть шанс встретить матричные принтеры на подключении к LTP-портам. Это даже не универсальные COM-порты, нет, которые можно встретить сегодня в мутированном виде клавиатурных гнёзд. Старый добрый LTP! В этих же банках отчёты сдают на 3,5-дюймовых дискетах. Даже у нас есть пара дисководов на случай горячей замены на складе. Там же ещё лежат суперсовременные ZIP-дисководы. Хорошо хоть 5,25 и 8 дюймов не встречали пока в практике. Хотя саму «грампластинку» — гибкий магнитный диск формата 8 дюймов в конверте — я ещё встречал в хранилищах ЗИП. Дисководы — нет.
Из современной истории в регионах можно часто повсеместно встретить старые компаковские сервера. Которые лет 10 назад поставлялись. Это ещё 2004-й, до слияния с HP.
А что Huawei?
А их разработка допиливает драйвера и прочее. Производитель железа должен поддерживать целевую ось аппаратно. Старые х86 были на интеловых чипсетах — это небольшие машины. У хьюллета — 16 ядер и выше. И железо у них для разруливания нестандартное. Поэтому не всё так просто, как может показаться. Те же менеджеры памяти очень нетривиальны для старых систем.
В итоге на выпуске нового сервера в начале список совместимости из одной ОС. Позже допиливают. Сейчас хотят больше глубоких NIX. Выбор-то простой: либо ПО системное переделывать, либо работать с операционной. Поэтому второе проще, потому что в банках распространён тот же Центос бесплатный (и даже не Редхат), и если дать совместимость — клиентов на х86 сразу станет больше.
Естественно, миграция может привести к переписыванию всей системы. И этого никто не хочет особо. Чаще всего разрабы потерялись, потому что системе 11 лет, нет актуальной документации или она не ведется. Найти хотя бы точки интеграции — стандартная проблема. Хранимые процедуры тоже добавляют радости. Ну и напоследок, 90% диалогов:
— У вас процедура принятия в эксплуатацию есть?
— Конечно!
— А документация по ней нужна?
— Абсолютно.
— Так, а эта процедура соблюдается?
— Нет, конечно, вы чего, с ума сошли?
Итог — документально процедура очень сложна, и никто не соблюдает, оставляют системы в тестовой эксплуатации.
Так что только переход на суперкластеры с совместимостью со старыми ОС.
Тесты
За 2 месяца мы протестировали для заказчиков 5 платформ. Обследовать по сути нечего, вопросы только по стабильности и возможности миграции. Никаких синтетических тестов, потому что результаты каждый раз разительно отличаются от реальных. Причём в обе стороны.
Будущее
В далёком будущем, возможно, таких танцев с бубном не будет. Самая главная беда, когда нам нужна вертикальная масштабируемость (увеличение количества процессоров и памяти в рамках одной машины), так как единую базу Оракл просто так нельзя разбить на несколько частей, она должна быть единой. А это хотят сделать все, чтобы перейти в облака и просто втыкать блейды в своё удовольствие. Сейчас большие СУБД на AIX единые и очень жирные. Поэтому вертикальный масштаб — для х86 сейчас это 32 процессора, по 16 ядер.
Сейчас все идут в сторону in-memory-вычислений, поэтому параллелить в любом случае будут. Вопрос в том, когда.
Автор: КРОК
