Что осталось на сейчас, и где начинаются проблемы восприятия.
Когда кто-то пишет свою первую программу, она, очевидно, сначала хранится на жестком диске. Он, конечно, уже давно не диск, а привод, Solid-State Drive, хотя и механические диски еще не сдали свои позиции. Но, конечно, сейчас уже не то – эпоха дисков на 15.000 оборотов закончилась в 2016 году, диски 10к потихоньку умирают, если не умерли совсем – объемов выше, чем 2.4TB SAS 10K SFF (HPE 881457-B21) я не видел. Это все те же Seagate Exos 10E2400 из 2020 года, что-то уровня ST2400MM0129. Все что позже – 7200. Не знаю даже – живы ли ноутбучные 5400. SSD подешевели, милорд. Но, что-то я ушел от темы. Проще сказать, что SSD выбили HDD с огромной части рынка, и идти дальше.
Когда у вас один диск в системе, и нет задачи обеспечения доступности хотя бы с 8 утра до 20 вечера с понедельника по пятницу, с перерывом не более часа, то вопрос отказоустойчивости не стоит. На малых объемах, и при отсутствии требований по доступности, хоть раз в месяц на внешний диск, или в облако*, или и туда и туда, свои данные копируйте, и все будет отлично.
*Кроме российских облаков, конечно, которые могут лежать и сутки, и неделю, и потерять данные совсем.
Когда возникают хоть какие-то требования по доступности, обязательно подкрепленные грязными зелеными бумажками, начинаются изучения вариантов «как повысить доступность данных».
Еще раз: если потеря данных не стоит «ничего», если простой считается как «бесплатный», то и беспокоиться не о чем.
Один из самых старых методов – собрать массив из дисков, Redundant Array of Independent Disks. Raid. Обеспечили избыточность в 1,2,3 диска (при этом зеркало (Raid-1 \ Raid 10\ Raid 50), не дает защиты от выхода из строя двух ЛЮБЫХ дисков), и все хорошо, и относительно недорого – нужны только диски, хотя желательно (не обязательно) иметь аппаратный RAID контроллер. С аппаратными контроллерами свои сложности, с программными - свои. Про MS Storage spaces, Storage spaces direct и LVM будет ниже (или нет).
Ок, от выхода из строя 1,2,3,N дисков застраховались, но на пути к доступности данных еще много препятствий. В обычном сервере (не рассматривая BullSequana и очень толстые IBM) отказ любого процессора, модуля памяти (с оговорками, не все вендоры серверов умеют исключать из работы модуль памяти с некорректируемыми ошибками), сетевой карты, итд – ведет к потере доступности данных. Хорошо, если «перезагрузили и заработало», но как быть, если «перегрузили и не работает»? Сами данные, может, и целы, но сервис, работавший с этими данными, не доступен.
Сноска: интересна ситуация со старыми Lenovo и Supermicro в blade системах. Я сталкивался на HS-22, коллеги ловили такое поведение на Supermicro. Сетевая карта просто пропадает из системы, но возвращается не после перезагрузки, но только после полного обесточивания лезвия. Выключили лезвие, выдернули из слота, подождали минуту, вернули – сетевая карта на месте. Может снова пропасть через 3-6 месяцев. Начинается такое поведение через 5-7 лет работы.
Есть много других неприятностей, таких как одинокий коммутатор. Или стек коммутаторов – стекированные коммутаторы при обновлении время от времени отказывают всем стеком, при этом встает намертво что элитный Cisco vPC (Virtual Port-Channel), что другой обычный порошок коммутатор с MC-LAG (Multi-Chassis Link Aggregation Group). В том числе поэтому в проприетарных решениях уже давным-давно есть Switch Embedded Teaming (SET) и vSphere Standard Switch с active-active, что позволяет выкинуть проблемы с отказом стека, и получить не менее (не)приятные проблемы при других сценариях отказа.
После всех размышлений, оказывается, что для решения проблемы отказа одного сервера – надо хотя бы два сервера (до георезервирования дойдем чуть позже). И два коммутатора, но лучше четыре – два под обмен обычными данными, и два под сеть передачи данных хранения. И не пускать во вторую сеть никого, особенно не пускать сетевиков. Простая, надежная сеть с включенным RDMA и настроенным DCB (или DCBX - data center bridging eXchange, ECN - Explicit Congestion Notification, Priority Flow Control)).
Как данные передавать будем? Есть несколько вариантов решения, самый простой – SAS корзина, осталось только как-то убедить операционные системы не конфликтовать друг с другом и не писать в один блок на дисках – разные данные, что тоже не так просто.
Поэтому возникает не самый простой вариант, точнее два.
Первый. Синхронизацией данных занимается операционная система. Записали данные на одном сервере, отправили блоки данных на другой, записали там, получили со второго сервера «ок», отчитались приложению (или нет). Как DRBD.
Второй. Два приложения на двух серверах могут и сами позаботиться о надежности. MS SQL и Oracle Real Application Clusters умеют в репликацию данных «из коробки». Oracle с 2001 года, MS - не знаю, в версии SQL Server 2008 R2 уже был Failover Cluster. В Postgre вы попляшете вокруг pacemaker, corosync, patroni (и к нему etcd), vipmanager, PgBouncer, pgpool-II, Slony, Stolon и еще чем-то, и потом попляшете с WAF. Обычно это теперь работает, хотя еще недавно (2016 год) Uber сказал «ну нафиг». Прошло уже столько лет, сейчас есть вроде живой Autobase for PostgreSQL. Решения есть, выбор за вами.
Все это отлично работает, пока вы оперируете 1-2 серверами. Ну 3-4. Ну 10. И пока у вас на складе всегда есть запасной сервер, или вам по гарантии привезут все, что надо за 1-3 бизнес-дня. Отказал сервер – не беда, достали холодный, поставили ОС, а хоть и ироником, или поставили и прокатили плейбук или воткнули под DSC -
Нащяльника, мая сервира паставиль, фрибизьдя инсталя сделаль, апачи сабраль, пыхапе патключиль, сапускаю, а ано - ажамбех пашамбе эшельбе шайтанама!
В комнату входят виртуализация и контейнеры.
Все, что выше, хорошо выглядит на примере baremetal. Когда в системе все четко - один сервер, одна программа, одна база данных, один монолит. (Гусары, молчать). Только это дорого – на современном сервере по 12-90 (на arm до 192 ядер у Ampere, и обещают 256) ядер на сокет, 2 сокета, и даже если ставить туда всего 2 модуля памяти по 64 Гб «из экономии», то все равно как-то не экономично получается. Потому что оперативная память ничего не стоит на фоне всего остального. Получается, что сервер на 90%, а то и 99.95% простаивает.
Почему? Потому что часть программ, как та же 1с – не умеют в многопоточность без особой магии, да и с магией не умеют. А если за дело берутся маркетологи, которых по недосмотру не усыпили, да потом они же пишут статьи «как настроить 1с», не понимая ни как работает турбобуст, ни как работает переподписка и планировщик, и даже не пробуя читать ИТС и настройки параметров рабочего процесса, то тут ничего не спасет от закупок baremetal. На Core i9. Техническая безграмотность, но оплаченный маркетинг – получаем безграмотные статьи в корпоративных блогах. Про это я попозже напишу, была тут эпичная битва двух якодзун на одном сайте.
В остальных случаях возникает экономическая потребность и выгода от виртуализации. Конечно, можно обойтись и без нее, но разбираться в хитросплетении зависимостей от разных библиотек зачастую экономически бессмысленно – на выяснение может уйти 8, 16, 40, 240 рабочих часов. Дешевле разнести приложения по разным виртуалкам. Попутно можно получить кучу бонусов, наподобие HA, FT, vmotion, и так далее.
Но. Если у нас внизу, в аппаратном сервере, нет доступного разделяемого внешнего хранилища, то мы будем вынуждены перемещать данные с сервера на сервер для любого обслуживания сервера, или делать какое-то иное резервирование. Про HCI будет позже, в самом низу.
Это возможно, но есть проблема роста объемов данных.
Одно дело, если у вас скромные 10-20-200 гигабайт данных. С современными дисками, с современной хотя бы 25G сетью, даже с давно уже копеечным, неуправляемым 10G коммутатором, без MPIO вы получите на чтение и запись что-то около 0.5 – 0.7 гигабайта \ секунду, 30-40 гигабайт в минуту. 5-10 минут и 200 гигабайт переместились, все рады. А если там система в 2 терабайта? Полтора часа туда, полтора часа оттуда, и необходимо на каждом сервере держать немалый запас свободного места. Плюс иметь на каждый сервер по запасному диску на горячую замену. Плюс на каждом сервере теряется 2 диска на Raid 6.
10 серверов – минус 30 дисков просто для отказоустойчивости, и еще держать свободный объем на 2 самые крупные базы данных, или хранилища, или что-то. Даже если скриптами подбирать конфигурацию оптимального размещения по объему, может возникнуть проблема шумных соседей, когда две базы (или два сервиса) что-то одновременно пишут. Для SSD это не так критично, но RAID берет свое, даже на SSD и NVME. Особено на NVME. Или вдруг два бекапа запустились, и сеть забилась.
Зато, до какого-то предела, наглядно и дешево, не надо никаких систем хранения данных.
Тут вы, конечно, скажете – товарищ Отрепьев, а вы ж врете и не краснеете, зачем нам RAID, если мы разносим данные на уровне серверов. Значит, достаточно LVM, или базу по файлам или партициям разделить по sda, sdb и далее. И я отвечу – все так и есть, вообще без проблем. Восстанавливать потом как будете, переливать весь объем данных, или настраивать репликацию диск в диск, причем с авто восстановлением конфигурации? Можно и так сделать, только насколько это удобно и надежно? Или все же RAID, чтобы система сама выкинула неисправный диск и пошла работать?
Но.
С RAID возникает еще 1 проблема, которая порождает сразу 3 других. И эта проблема – восстановление при сбое.
Проблема №1. Raid 5 не очень надежен на механических дисках, и особенно диски consumer \ home grade.
Математика ребилда известна, при объемах данных в терабайты и обычных (не enterprise) механических жестких дисках и домашних \ consumer SSD шансы потерять данные:
6 дисков по 2000 Гб, ошибка 1*10(-14) – шансы на потерю данных 55-65 % на каждом ребилде. Калькулятор 1, калькулятор 2.
Шансы потерять данные за 2 года эксплуатации при оптимистичном MTBF в 250.000 часов – 20%. Калькулятор 3. При консервативном подходе – 33% риска потерь за 2 года эксплуатации.
С ростом объемов риски растут, и использование 10 дисков по 4 Тб в R5 с даже в 10 раз меньшим числом ошибок (1*10(-15)) дает что-то порядка 80% удачи, 20 % неудачи, и 10% риска потери данные за первые 2 года эксплуатации дисков (при консервативной оценке MTBF).
Простая математика:
Consumer SSD error rates are 10^16 bits or an error every 1.25PB.
Enterprise SSD error rates are 10^17 bits or an error every 12.5PB
Статья: Flash banishes the spectre of the unrecoverable data error
Если у вас хранятся пользовательские фотографии, или какое-то видео котиков, то испортился бит, или потеряли этих котов десяток – да и наплевать. Вот бы еще все было так просто, что случилась ошибка на ребилде, и было бы сразу понятно, что ошибку можно пропустить, и будет потерян всего лишь звук загрузки и два пикселя фотографии кота на рабочем столе. А если нет? Нехорошо как-то. Особенно нехорошо, что при ребилде нет кнопки «пропустить». Придется тащить диски в какую-то лабораторию (которых еще поискать), перечитывать данные еще раз (может, прочитаются, может и нет), тратить какие-то деньги на все эти операции, все это время система без дисков будет или стоять, или работать на только втором сервере.
Raid 10 тут в чем-то хуже, хотя перечитывать и восстанавливать нужно суммарно только объем одного диска. Зато можно внезапно обнаружить, что второй диск тоже умер, просто его не давно не проверял никто в фоновом режиме.
Проблема №2. Работа под нагрузкой при ребилде
Пока все данные пересчитываются и перечитываются, какой-то % дисковых операций тратится на них. Параметр регулируемый, но все равно, на время ребилда классического рейда, эта нагрузка, скорее всего, будет так или иначе заметна. При этом диск в плохом случае вылетит не в пятницу вечером, а в середине расчета зарплаты.
Проблема №3. Скорость ребилда
Поскольку надо восстановить целый диск, то все восстанавливаемые данные будут писаться на один диск, через его один интерфейс. Это долго, это часы и даже дни. Использовать raid 2.0 \ draid – raid контроллеры пока не умеют.
С контейнерами все становится или лучше, или хуже, это как посмотреть.
Пока контейнеры живут, как и положено, в режиме «жил жил, пока не умер – stateless», ничего страшного не происходит. Умер Максим, и ладно. В доме заиграла музыка, k8s\ k3s\ прочие оркестры сыграли марш и подняли новые контейнеры. Как только в контейнере начинает жить что-то с записью на диск, stateful – тут же начинаются PersistentVolume (PV) и прочие драйвера к внешнему хранению. Вы скажете S3, облако, но в итоге данные все равно приземляются на те же SSD\HDD.
Итог. Если хотите высокодоступную виртуализацию, или не виртуализацию, то сначала определите, что для вас «высоко». Потом или стройте репликацию на каком-то уровне, со своими плюсами и минусами, или считайте стоимость внешнего хранилища, или, но про это чуть позже, готовьтесь к HCI - Hyper-converged infrastructure.
Еще раз: это всё, всегда, и без исключений – про деньги.
Бизнес, то есть генеральный директор, должен понимать, с точностью до значимых чисел, стоимость простоя, риски простоя в год, и стоимость инфраструктуры и людей для обеспечения этой доступности.
Можно сделать какие-то решения и на костылях, сделать свой SC VMM на скриптах, кронтабе, потом подтянуть API – весь инструментарий для этого есть. Но сколько времени займет написание своих костылей, и кто будет поддерживать эти костыли после увольнения писавшего? Особенно если код написан в спагетти стиле?
Системы хранения данных, год 2025.
Чтобы говорить про СХД, нужно знать и понимать хотя бы следующее.
Классическая СХД в вакууме – это СХД начального уровня. Деды вспомнят, может и без таблеток, про HP MSA2000 G2. Еще пока был единый HP. Или вспомнят Storwize какой-то. В общем, все, что было до появления божественной Евы 4400. Или, если это уже прадеды, то накидают боевых картинок со сменными блинами для дисков. Это уже не так интересно.
Современные СХД можно условно разделить на следующие группы:
Почему условно? Потому что термин не закреплен в ISO \ IEEE \ ГОСТ, и любой маркетолог может сказать «это СХД». Была даже такая редакция Windows - Windows Storage Server. Может, кто-то вспомнит VNX.
Группа 1. Вообще не СХД.
Это и программные решения, типа Raidix, и Synology RackStation RS1221RP, и много лет рекомендуемый лучшими майнерами и их друзьями Infortrend, и тот же Ceph. Тысячи их. Хотите считать эти изделия СХД – пожалуйста, только не забывайте, что у них или по 1 процессору и материнской плате, то есть или по одному контроллеру, или для них нужно хотя бы три сервера. Лучше пять. Или они просто кривые, который год.
Лично для меня СХД начинается от «всего по хотя бы два» - два блока питания, два независимых контроллера. Можно 4 блока питания и 4 контроллера. Больше можно. Меньше нини. Контроллеры могут работать в каком угодно режиме, и с любым Path Selection policy (PSP) - Active/Optimized, Active/Non-optimized, Standby, это не так важно. Хотя как, «не так». Если у вас на СХД переключение путей при отказе контроллера идет больше таймаута на системе виртуализации, или больше таймаута на нагруженной системе внутри контейнера или виртуализации, а это может быть и 30 секунд, и 5 секунд, то система виртуализации может сказать (и скажет) – все мертво, All-Paths-Down (APD), Permanent Device Loss (PDL), и остановить ввод вывод. С последующими криками боли и унижения. Естественно, без вазелина. Как при этом Земля не проваливается в око ужаса, не понятно. Но про это позже.
Группа 2. СХД начального уровня, уже даже и гибридные.
Мир меняется, технологии растут и дешевеют. Лет 20 назад тиринг и динамические рейды только появлялись «для масс», сейчас они почти везде. Даже не найду, когда появился тиринг, в 2011 году уже был. В 2008 году был. Истина где-то рядом.
10 лет назад all-flash-array (AFA), то есть СХД с софтом, оптимизированным на работу только с СХД, стоили совсем других денег, чем сегодня Huawei OceanStor Dorado 3000 V6.
Очередное пояснение. У Huawei сейчас используется следующее деление в маркетинге, которое многих путает. OceanStor – это «вообще все СХД», OceanStor Dorado – линейка all-flash-array, v6 – поколение. Рисовать таблицу не буду.
Поэтому получается так:
СХД начального уровня = СХД малой производительности, с урезанными функциями относительно старших моделей в ряду. Сложно расширяемые - например, нельзя подключить внешние дисковые полки. Хотя, этот пункт тоже под вопросом, полки HP D2600 и D2700 числились как совместимые с HPE P2000 G3 FC Modular Smart Array System.
Гибридные СХД – системы, в которых можно одновременно использовать механические и SSD диски. Таких систем полно.
All-flash-array (AFA), русский перевод термина отсутствует за ненужностью. Это СХД, работающие только с SSD. Теперь (уже лет пять?) есть и начального уровня, относительно задешево. Dorado 3000 например.
У СХД среднего уровня добавляется и производительность, и надежность. Для AFA к All-SAS SSD добавляется ALL-NVME SSD, с их оптимизациями под NVMe over Fabrics (NVMe-oF) и NVMe over RDMA over Converged Ethernet (NVMe over RoCE). С последними поколениями коммутаторов на FPGA Xilinx UltraScale VU9P, скажем Arista 7130E с их задержками в 50 ns, все становится очень интересно.
Маркетологи в Arista ленивые, просто ну невозможно. Могли бы и поменять что-то, а то пишешь статью и узнаешь, что были Arista 7130 Series 48E, стали Arista 7130 Series 48L with UltraScale VU7P-2 FPGA, еще в 2021.
Хотя в Cisco и 80 ns рады. На 400 GbE портах.
Добавляется лицензирование метрокластера, добавляются всякие онлайн дедупликации и компрессии, иногда и офлайн, добавляется возможность поставить не 2 контроллера, а 4.
У кого-то добавлялись (или уже нет, я не успеваю следить за сменой 3Par на Alletra) возможности резервировать данные на случай отказа не только одного диска, а целой дисковой полки. Добавляется маскарадинг, или как это не назови – когда можно спрятать старую СХД за новыми СХД, и данные со старой СХД будут доступны через контроллеры и интерфейсы новой. Прочие бонусы, пусть про них маркетологи рассказывают.
У старших моделей, то что у маркетологов называется mission-critical storage, добавляются надежность, но, прежде всего, меняется архитектура связи контроллеров. Самих контроллеров можно ставить 16-32 штуки, дисков чуть ли не 10-20 тысяч штук, итд итп. Дорого, богато, объемно, быстро, надежно.
Лидеров по тратам маркетингового бюджета, как и раньше, можно смотреть в квадрате Gartner.
Отдельно в тех же квадратах введено разделение:
Primary Storage Platforms
File and Object Storage Platforms
Full-Stack Hyperconverged Infrastructure Software
потому что, как иначе продавать рекламу и места в квадрате для всех участников рынка?
Имена всех участников более-менее на слуху: Dell PowerMax, HPE Alletra Storage, Netapp, Pure Storage, Lenovo, Fujitsu (они еще живы? Оказывается да), Hitachi Vantara (тот же вопрос), Huawei, Infinidat, почему-то Inspur и даже Infortrend.
Что предлагается тут для повышения надежности хранения и повышения доступности в среднем и старшем, а то и в младшем сегменте рынка?
Ничего особенно нового.
Локально – все те же вариации на тему Distributed RAID - Lenovo ADAPT, IBM distributed RAID (DRAID), Huawei Raid 2.0, Netapp SANtricity Dynamic Disk Pools (DDP), и так далее. Очень удобно, очень быстро. Быстрее разве что фоновая подготовка к отказу диска, есть такая модная тема.
Глобально – тоже ничего нового, метрокластер и синхронная или асинхронная репликация, смотря что хотите.
Для любителей кластеров подлиннее есть и Synchronous Long Distance (SLD).
Иногда теперь внутри стоит «что-то такое про Artificial intelligence (AI)» - который обрабатывает кеширование, и какие-то маркетинговые (как сейчас продавать что-то без пометки AI? Никак), и внутренние задачи.
Чуть было не забыл про «все для тестов и резервного копирования» - снимок (снапшот) тома, синхронный снимок группы томов, презентация снимка кому надо – например, для того чтобы быстро отдать копию боевого тома в тесты, или сделать бекап клона тома. Само собой API для обеспечения работы систем резервного копирования.
Конечно, батарейки для поддержания кеша в живом состоянии. И многое другое, всякие там аналитики отказов, звонки другу, счетчики ресурсов итд итп. Драйвера под Openstack само собой.
Програмно-определяемые СХД, Software-defined storage (SDS).
Как говорит википедия, Software-defined storage (SDS) is a marketing term ..
Термин очень и очень маркетинговый, потому что почти все современные СХД, так или иначе, программные. Зачастую на все тех же x86, или на arm. Базовая ОС – скорее всего варианты с ядром Linux. Внутри может быть пара контейнеров для обеспечения файлового или S3 доступа. Внутри иногда можно даже запустить свой контейнер или виртуалку, с массой ограничений, но можно.
Продают их примерно все вендоры, и ничего плохого в этом нет. Вопрос в том, сколько в продукте маркетинга, а сколько технической составляющей. Отдельно надо сказать, что имеет значение и цена, и выбор масштабирования – горизонтальное или вертикальное.
Хочется хранить больше пиратского кино в старом добром формате «8 фильмов на 1 DVD» - ваш выбор горизонтальное масштабирование, много дешевых серверов с дешевыми дисками и резервированием x3.
Хочется высокой скорости и отсутствия простоя, пока на ЦОД Госзнак идет восстановление - выбираете дорого, богато.
Что там на слуху? Ceph, linstor, Vitastor?
В чем главный минус всех этих решений? Это дорого.
Дорого не в смысле разовых вложений, запустить все это можно на любом железе из ларька бу техники. И это даже будет работать. Ничего сложного в первом запуске нет. Если у вас 3 БУ ПК, нет требований к надежности, нет требований по скорости (линейной или IOPS), нет задачи обновления, нужно «просто чтобы работало» - берете 3 ПК, собираете, работает. Потом увольняетесь, пока само не упало. Можно даже запустить виртуализацию там же. И даже что-то заработает, то есть запустится. Идеальное решение для статьи корпоративного блога на Хабре, скажем, для МТС. Особенно, если не писать «да, наше облако упало и лежало неделю, потому что». То есть, если у облака с таким хранилищем нет в соглашении крупного штрафа за простой, в деньгах, а не в «скидке 5% на следующий месяц», то они могут хоть Ceph ставить, хоть писать что они не смогли что-то сделать с Openstack и выбрали Cloudstack. То же самое, только сбоку.
Отказываться от VMware Cloud Foundation русские облака не спешат. Мировые, впрочем, тоже. Да, это дорого. Очень дорого. Клиент платит.
Если не считать TCO, total cost of ownership, и умело считать CAPEX и ФСБУ 26/2020, то Ceph выглядит дешевле. А если считать? И если прибавить требования со стороны прочих департаментов \ отделов \ etc?
Очередное отступление в сторону.
Может показаться, что Ceph выглядит в этом тексте как мировое зло, на фоне светлого и прекрасного корпоративного решения «задорого», в то время как для фирмы бесплатный Ceph выглядит идеально. Затраты на лицензии ноль, затраты на поддержку у фирмы – ноль (планируется, что его развернет и подключит имеющийся штат), собрать можно на двух HPE Gen 6 с процессором на целых 4 ядра возрастом 12 лет, что может пойти не так? Дада, мы (менеджмент) конечно тебя услышали. И что надежность низкая, и что может упасть, что нужно купить что-то под бекап, обязательно купим в следующем году. ЧТО ЗНАЧИТ УПАЛО И ТЫ ПРЕДУПРЕЖДАЛ? НЕДОСТАТОЧНО ПРЕДУПРЕЖДАЛ! ВИНОВЕН!
Российский, и не только российский, бизнес, очень любит перекладывать риски и переводить стрелки на исполнителя. Упал сервис – виноват Вася, недостаточно часто обращал внимание руководства на состояние и риски. Слишком тихо и редко кричал. Почти всегда, за очень редкими исключениями, бизнес будет переходить к теме «я начальник, ты дурак, начальство не ошибается - значит, ты виноват». Единственный работающий способ – не трогать любую потенциальную дрянь даже палкой. Никак. Никогда. Спорить с начальством, наслушавшимся сына маминой подруги, прочитавшего 1.5 статьи в маркетинговом копроблоге, бесполезно – есть два мнения, его и неправильное. Конфликт с начальством вообще не продуктивен. Но, иногда приходится выбирать:
– Вступать с размаха в очевидные проблемы, тратить дни и ночи на разбирание в многолетном наслоении питоновых отложений, и все это за ту же зарплату, получая вообще не оцениваемый на рынке в рублях или долларах опыт починки, сидя по шею в этих отложениях, или
- Увольняться. Заявление на стол, дальше не твои проблемы. Все эти рассказы в фирме «мы семья, мы команда» заканчиваются с первыми признаками проблемы.
Сам продукт при этом не плох, не хорош. У него есть своя ниша, свои понятные характеристики, поведение итд. В пределах этой ниши он может выполнять свои задачи. В очень, очень узких пределах, на нормальном железе, настроенный под задачу, после полугода тестов и 3-5 разносов стендов.
Если говорить про аналогии, то и система BASE-STEP (запущена 24 октября 2024) и тачка для навоза на даче, решают задачу доставки чего-то из точки А в точку Б. Только стоят по разному, и не все можно перевозить на тачке, и не всё стоит перевозить на BASE-STEP – если в BASE-STEP сунуть навоз, то может рвануть.
Но нужны обе. На своем месте.
Модное веяние последних 10 лет – HCI. Hyper Converged Infrastructure
В какой-то момент, с ростом количества и качества ИТ, внедрения «всего» и «везде», фирма приходит к какому-то равновесию. На каждый новый сервис в среднем нужно сколько-то ядер, сколько-то гигагерц. Нужна память. Нужно дисковое пространство. Становится удобнее оперировать одинаковыми серверами, подключенными к 1-2 системам управления. Таким, как Intel Data Center Manager, Aria Operations Management Pack, HPE OneView и так далее. Сводные отчеты, сводные таблицы, автоматизация везде и всюду.
Возникает идея – зачем нам СХД, если у нас и так и так есть сервера с отсеками под диски. Давайте сделаем систему с распределенной программно-определяемой СХД, которая будет работать с нашей системой виртуализации и с локальными дисками. Возникает redundant array of inexpensive servers (RAIS) или redundant array of independent nodes (RAIN). Очень удобно. Уперлись в потолок – купили еще 1, 2, 6 стандартных единиц, добавили в систему, дальше оно само. Хотите такое же, но ориентированное именно на хранение – можно и так, просто поменяйте настройки и занесите деньги по счету. Хотите не 2 петабайта, а 4,6 – пожалуйста, проходите в кассу. Скорости – отличные, надежность (обычно) – 4-5 девяток, 99.99 – 99.999.
Ограничения – да почти никаких, можно начинать строить хоть с 2 серверов, даже без коммутатора. Shotgun mode и понеслась.
Минусы написаны мелким шрифтом:
Очень узкий список протестированного на совместимость оборудования.
Очень высокие требования к квалификации эксплуатирующего персонала. Особенно сетевиков, которые зачастую не готовы читать про требования к RDMA, и не понимают, как и зачем реализованы что Switch Embedded Teaming, что Network Air Gaps.
Обманчивая простота снаружи, при этом внутри надо знать «как» и «как именно» это работает, а не только в GUI кнопки нажимать.
Отвыкать, точнее ни в коем случае не лечить проблемы ребутом.
Как же без него. Про облака, все, есть три заблуждения: что это быстро, надежно, дешево.
Ничего подобного. «Быстро» в российских облаках предполагает какие-то очень костылизированные решения. Аналогов классов хранения по моему нет ни у кого.
Надежность применительно к российским облакам, которые могут валяться и сутки, и неделю, но все это время маркетологи строчат статьи «у нас все хорошо», вообще не применима.
Дешево .. это как сказать. Во сколько вам обойдутся сервисы, лежащие час в облаке?
В иностранных облаках ситуация принципиально другая. Или нет. Не то, чтобы они порой не лежат. Лежат, и еще как. Недавно опять часть Azure лежала три дня, с 8 по 11 января.
Вот отчет: 01/08/2025 Post Incident Review (PIR) – Networking issues impacting Azure Services in East US 2, Tracking ID: PLP3-1W8. Что сломалось, почему сломалось, как сломалось. Особенно если вчитываться, и понимать, какие смуглые друзья и дефективные Кумары и их такие же менеджеры стоят за строчками
All manual configuration changes will be moved to an automation pipeline which will require elevated privileges.
Consider ensuring that the right people in your organization will be notified about any future service issues
Но. Хотя бы вышла и статья, и разбор, и обещания все исправить.
