Comments 27
Так, ну vendor-lock, конечно, бывает. Но iSCSI вроде один на всех, не? И чтобы NVMe выжать из СХД, с ней надо дружить по быстрой и отзывчивой сети. Если мы не в виртуалочках на локалхосте этим-вот-всем занимаемся, то это Infiniband. Вы его тоже умеете готовить?
Не совсем понял ваше сравнение с Infiniband, давайте я попробую рассказать свою точку зрения, Infiniband — протокол который активно внедряет Mellanox, мы про них хорошо знаем, но что они сделали? Существует ниже Infiniband протокол PCI express, который кстати также является коммутируемым, там также есть CRC и основан он на транзакциях, там есть кодирование на канальном уровне. Уже придуманы коммутаторы PCI express и они дают значительно меньшую latency чем Infiniband. Зачем тогда Infiniband? С коммерческой точки зрения — дорого и прибыльно. С технической единственный плюс в том, что написано много клиентского софта для IB и не нужно искать драйвер для ОС клиента. А вот с точки зрения lock-in вендора тут засада, дело в том, что IB сидит на PCI express шине и даёт накладные расходы сразу, так как он реализует свой логический уровень и игнорирует PCI express, используя его как транспорт внутри системы между памятью RAM и процессором. Мало кто об этом знает и все считают IB единственным выходом, однако это не так, мы сейчас проектируем свой адаптер на базе PCI express и чипов от компании Microsemi.
По поводу iSCSI, честно говоря это очень странный стандарт, дело в том, что FC к примеру был разработан специально как транспорт для SCSI, а также были придуманы коммутаторы и специальное оборудование на базе FPGA от CISCO и Brocade, чтобы создавать SAN.
Т.е. комитет T10/T11 NCITS состоящий из ряда базовых компаний в Штатах в этой области договорился развивать FC для нужд СХД и передачи данных.
С TCP/IP изначально было всё не так. Решили просто посадить SCSI туда и придумали RFC для iSCSI, который несёт массу накладных расходов, так как сетевые карты знать не знают о том, что они передают. В моём понимании iSCSI это очень экспериментальный стандарт.
Т.е. комитет T10/T11 NCITS состоящий из ряда базовых компаний в Штатах в этой области договорился развивать FC для нужд СХД и передачи данных.
С TCP/IP изначально было всё не так. Решили просто посадить SCSI туда и придумали RFC для iSCSI, который несёт массу накладных расходов, так как сетевые карты знать не знают о том, что они передают. В моём понимании iSCSI это очень экспериментальный стандарт.
О, Великий Макаронный Монстр! Двадцать лет с момента изобретения iSCSI прошло, ровесники его уже школу закончили, технология успела получить признание, распространиться, поработать и даже в значительной степени уже устареть постепенно, а у передового российского вендора СХД она все еще «экспериментальный стандарт».
Вот все, что вам нужно знать про передовых российских вендоров СХД и инновации в них.
Вот все, что вам нужно знать про передовых российских вендоров СХД и инновации в них.
Вы меня неверно поняли, во-первых я не против iscsi, он замечателен сам по себе, например не нужно разрабатывать сложное железо, а достаточно иметь сетевую карту и можно хоть на своём ноуте заниматься разработкой на базе iscsi.
Мне это нравится и это здорово, но СХД это не просто iscsi, СХД гораздо сложнее, если мы пытаемся решать сложные задачи и гарантировать надёжность данных.
Мы используем и поддерживаем iscsi тоже в своём СХД.
Для реальных задач всё-таки FC не уходит с рынка, так как сетевое оборудование Ethernet не может обеспечить надёжной доставки данных для серьёзных высоконагруженных задач, обслуживая мимоходом ещё сетевые запросы клиентов, MPLS и т.д. Но выделенные Ethernet сети думаю можно применять для задач SAN, но осторожно :)
Мне это нравится и это здорово, но СХД это не просто iscsi, СХД гораздо сложнее, если мы пытаемся решать сложные задачи и гарантировать надёжность данных.
Мы используем и поддерживаем iscsi тоже в своём СХД.
Для реальных задач всё-таки FC не уходит с рынка, так как сетевое оборудование Ethernet не может обеспечить надёжной доставки данных для серьёзных высоконагруженных задач, обслуживая мимоходом ещё сетевые запросы клиентов, MPLS и т.д. Но выделенные Ethernet сети думаю можно применять для задач SAN, но осторожно :)
Да как вас можно неправильно понять, если вы сами пишете это, утверждая однозначно, что технология, изобретенная 20 лет назад, вошедшая в ядро Linux, дайбохпамяти, 2.6.20 (!), и все эти 20 лет активно используемая в самом сложном энтерпрайзе, — у вас «экспериментальная».
Вы и продолжаете про FC дальше.
Ну, говорю же, ваши инновации отстали от bleeding edge лет так на 10, на беглый взгляд. _Вообще_ ничего, чем сегодня живет IT infrastructure в мире. Все «старые песни о главном» на новый лад. Такое ощущение, что вы 10 лет в заморозке в бункере провели.
Вы и продолжаете про FC дальше.
Ну, говорю же, ваши инновации отстали от bleeding edge лет так на 10, на беглый взгляд. _Вообще_ ничего, чем сегодня живет IT infrastructure в мире. Все «старые песни о главном» на новый лад. Такое ощущение, что вы 10 лет в заморозке в бункере провели.
Вы конкретно напишите про что Вы дискутируете? я не понимаю суть Вашего вопроса. Какие 10 лет и вообще Вы о чём, в каком сложном Enterprise? Мы знаем все сложные Enterprise? Скажу Вам так, маркетинговая крышка и слова Enterprise призваны разделять решения на категории для привелигированных и всех остальных. А на практике High End у всех компаний не стоит тех денег за которые его продают. Может быть Вы не в курсе, но компании западные продают одно и тоже железо под маркой High End просто меняя ценник в 4 раза выше.
ПОтом внешний интерфейс в СХД не имеет никакого значения, вообще сравнивать СХД по внешнему интерфейсу доступа к данным не имеет смысла вообще, мы можем встроить любой интерфейс, просто FC все любят и многие ему доверяют на рынке, что вполне оправдано.
ПОтом внешний интерфейс в СХД не имеет никакого значения, вообще сравнивать СХД по внешнему интерфейсу доступа к данным не имеет смысла вообще, мы можем встроить любой интерфейс, просто FC все любят и многие ему доверяют на рынке, что вполне оправдано.
Да, и админ Петя, с большой вероятностью, говорит с системами не на С++, если что. Что не мешает ему собрать систему из opensource-компонентов, если у начальства с бюджетом вдруг станет туго.
Согласен, админу не нужно С++ знать, поэтому мы сделали ещё и Python :) Open-source много не умеет, например обновить код Opensource систему без остановки нельзя, а у нас можно, мы это специально делали. Потом есть архитектурные отличия нас от Opensource, в итоге получается что поддерживать OPensource, который много чего использует в Kernel сложно и дорого для компаний. Потом кто будет отвечать за СХД на Opensource, админ? Для этого есть компания вендор, в частности мы развиваем продукт и обеспечиваем maintenance, support и т.д. А кто обеспечит гарантию того, что данные не потеряют? Мы проводим серьёзные тесты, сейчас в нашем репозитарии около 500 тестов, которые обязательно должны пройти перед тем как мы выпустим очередной релиз своей СХД.
Open-source много не умеет, например обновить код Opensource систему без остановки нельзя, а у нас можно, мы это специально делали
Да да, Ceph смотрит на это с презрением, не раз обновлял работающий кластер без существенного падения производительности и простоя
Ceph — это программно определяемая распределенная файловая система. Мы говорим про блочный Storage, разница очень большая. Например при обновлении микрокода нам не нужно перезагружать контроллер СХД, мы не теряем 50% пропускной способности во время обновления как это делают 2-х контроллерные конфигурации подавляющего большинства СХД.
Чем вам RBD не блочный сторадж? в случае с ceph я могу по одной две ноды выводить на maintainance и обновлять их без урона производительности, в случае с цефом, возможно очень быстро горизонтально увеличить емкость и производительность, у меня в данный момент в продакшене кластер цефа, 6 нод под iSCSI, 14 нод хранения(36x6Tb, 2x800Gb NVME) обьем RAW 2.5Петабайта replication factor=2 вся сеть передачи 2x10Gb на production и 2x10 cluster network
Давайте договоримся что именно мы обсуждаем, если с точки зрения клиента и пользователя СХД, то предлагаю просто сравнить архитектуру, у нас о есть описание в предыдущей нашей статье и здесь storequant.ru/pdf/STOREQUANT_STORAGE_PRODUCT.pdf
Но я попробую привести ряд аргументов в свою пользу,
1) Наша система кэш-based, это означает, что мы пишем данные сначала в кэш, перед записью на диск, и отвечает клиенту о завершении IO после попадания данных в кэш. Причина простая — тем самым мы повышаем производительность.
2) Все операции в кэш должны быть сохранены на диск, в случае аппаратного сбоя и у нас есть операция gracefull shutdown, что означает сохранение всех данных в кэш на промежуточный диск в случае shutdown системы. Т.е. данные в RAM мы не теряем никогда, у нас есть батарея в составе СХД.
3) Далее все операции IO дублируются как минимум на второй контроллер в паре.
ПОэтому если один контроллер сломается, второй сразу будет доступен клиенту для доступа к данным на томе.
4) Мы поддерживаем до 1024 контроллеров в сумме. Каждый контроллер это шасси с дисками с горячей заменой, т.е. замена дисков в Online.
5) Каждый контроллер может объединяться в пару с любым контроллером (до 8 макс) и выполняется это программно, без физической коммутации.
Но я попробую привести ряд аргументов в свою пользу,
1) Наша система кэш-based, это означает, что мы пишем данные сначала в кэш, перед записью на диск, и отвечает клиенту о завершении IO после попадания данных в кэш. Причина простая — тем самым мы повышаем производительность.
2) Все операции в кэш должны быть сохранены на диск, в случае аппаратного сбоя и у нас есть операция gracefull shutdown, что означает сохранение всех данных в кэш на промежуточный диск в случае shutdown системы. Т.е. данные в RAM мы не теряем никогда, у нас есть батарея в составе СХД.
3) Далее все операции IO дублируются как минимум на второй контроллер в паре.
ПОэтому если один контроллер сломается, второй сразу будет доступен клиенту для доступа к данным на томе.
4) Мы поддерживаем до 1024 контроллеров в сумме. Каждый контроллер это шасси с дисками с горячей заменой, т.е. замена дисков в Online.
5) Каждый контроллер может объединяться в пару с любым контроллером (до 8 макс) и выполняется это программно, без физической коммутации.
1. у ceph тоже сначала в кеш(wal/db на nvme диски), и тоже для повышения производительности
2. Как ни странно но вы не единственные кто юзает BBU на контроллере ))
3. В ceph данные дублируются на еще 2 OSD не расположенные в этом же сервере, итого имеем фактор репликации 3
4. Ну в вашей терминологии у меня 14 контроллеров(14 выделенных серверов хранения) максимальное количество даже страшно представить, в CERN'е хранилки на CEPH доходят до 30Пб, горячая замена по прежнему присутствует и активно используется, выход из строя 1/3 всего кластера не ложит систему на лопатки
5. В цеф это сделано через pool's, можно сделать only flash pool и использовать его как горячее хранилище, но при использовании nvme дисков и так производительности хватает
2. Как ни странно но вы не единственные кто юзает BBU на контроллере ))
3. В ceph данные дублируются на еще 2 OSD не расположенные в этом же сервере, итого имеем фактор репликации 3
4. Ну в вашей терминологии у меня 14 контроллеров(14 выделенных серверов хранения) максимальное количество даже страшно представить, в CERN'е хранилки на CEPH доходят до 30Пб, горячая замена по прежнему присутствует и активно используется, выход из строя 1/3 всего кластера не ложит систему на лопатки
5. В цеф это сделано через pool's, можно сделать only flash pool и использовать его как горячее хранилище, но при использовании nvme дисков и так производительности хватает
Я не против Ceph и все решения имеют место быть. Просто у всех есть свои недостатки и ниши. История Ceph не уникальная, до это были ряд решений, например HP Lefthand. Эти решения типа Ceph называются сетевыми RAID и имеют ограниченное применение, например установить на Lefthand СУБД какой-нибудь банковской АБС или высоконагруженный веб-портал магазина не реально.
У iscsi есть ограничение, оно продиктовано тем, что он работает поверх сетевого протокола и поэтому есть накладные расходы за которые приходится расплачиваться скоростью.
Теперь по пунктам,
1) Мы не сетевой RAID, мы блочный сторадж и его можно применять для любых в том числе и в первую очередь для высоконагруженных систем.
Кэш у нас устроен таким образом, что он разбивается на партиции и каждая партиция может обслуживать свой VOlume, гарантируя производительность.
2) Батарея не наше ноухау, просто это решение задачи когда есть сбой электросети или нужно удалённо погасить СХД без потери данных
3) Мы не дублируем данные, мы используем RAID, каждый диск у нас адресуется в СХД любым контроллером, например в нашем СХД любой контроллер может прочитать данные на любом диске, даже если диск не находится в локальном шасси. Если диски в RAID распределены так, что они находятся в разных шасси, то получаем NSPOF. Можно выбирать разный уровень защиты — с одинарной четностью или двойной. Все конфигурации RAID у нас были в первой статье.
Вобще дублировать данные на NVMe дорогое удовольствие, учитывая их стоимость.
4) Нужно всё-таки представлять масштаб проблемы, мы заточены для Российского клиента, который выбирает не RAID, а надёжность, если клиент потеряет данные, то вобще нет смысла заниматься этой темой. Наш клиент — это Enterprise, где нужна высокая скорость и надёжность.
5) Мы используем Thin Provisioning и объединяем в Pool группы RAID, в одной RAID группе может быть до 256 дисков, в Pool можно объединить неограниченное количество RAID групп.
У iscsi есть ограничение, оно продиктовано тем, что он работает поверх сетевого протокола и поэтому есть накладные расходы за которые приходится расплачиваться скоростью.
Теперь по пунктам,
1) Мы не сетевой RAID, мы блочный сторадж и его можно применять для любых в том числе и в первую очередь для высоконагруженных систем.
Кэш у нас устроен таким образом, что он разбивается на партиции и каждая партиция может обслуживать свой VOlume, гарантируя производительность.
2) Батарея не наше ноухау, просто это решение задачи когда есть сбой электросети или нужно удалённо погасить СХД без потери данных
3) Мы не дублируем данные, мы используем RAID, каждый диск у нас адресуется в СХД любым контроллером, например в нашем СХД любой контроллер может прочитать данные на любом диске, даже если диск не находится в локальном шасси. Если диски в RAID распределены так, что они находятся в разных шасси, то получаем NSPOF. Можно выбирать разный уровень защиты — с одинарной четностью или двойной. Все конфигурации RAID у нас были в первой статье.
Вобще дублировать данные на NVMe дорогое удовольствие, учитывая их стоимость.
4) Нужно всё-таки представлять масштаб проблемы, мы заточены для Российского клиента, который выбирает не RAID, а надёжность, если клиент потеряет данные, то вобще нет смысла заниматься этой темой. Наш клиент — это Enterprise, где нужна высокая скорость и надёжность.
5) Мы используем Thin Provisioning и объединяем в Pool группы RAID, в одной RAID группе может быть до 256 дисков, в Pool можно объединить неограниченное количество RAID групп.
ИМХО суть статьи сводится к некомпетентности Пети ни в пуско-наладке, ни в сайзинге, и судя по всему — это его первая СХД и отсутствие практического опыта. И дело тут не в SFP и вендорах, а в экономии руководства, которое не отправило админа на обучение (а у вендоров СХД оно крайне дорогое обычно) или не захотели платить за аутсорс энтерпрайз оборудования, с которым его сотрудники не имеют компетенций. Ну а с админом то всё понятно — ему надо куда то раста и развиваться, есть такой класс админов, которые могут и на продуктивных данных без бекапа учиться.
Вообще, мое мнение по статье, сводится к тому что, вот смотрите какая крутая у нас СХД, покупая DELL, IBM, Huawei вы становитесь заложниками vendor lock-in, а у нас супер СХД и вообще почти open-source, но мысль что отвязываясь от именитых брендов и привязываясь к местечковому вендору не покидает, со всеми вытекающими последствиями, примерно как в современной авиации, есть Boeing, есть Airbus, и есть например Туполев, если у А или Б самолет сломается в любой части земного шара, то максимум что грозит это ожидание ближайшего рейса с запчастью с ближайшего склада, в случае с Ту, это пока эту деталь закажут на заводе, сделают, и только через n-дней доставят до получателя вместе с командой техников…
Идея нашей статьи поддержать вообще создание и разработку отечественных СХД, если у нас будет больше компаний производителей, то мы только все выиграем от этого и сможем реально на рынке у нас сделать здоровую конкуренцию.
Трудно объяснить УАЗоводу, что важней «не сломается», а не «можно починить в любой деревне».
Согласен, нам это всё знакомо, решаем мы следующим образом, у нас сертфицировано 2 платформы сейчас, каждый может её купить сам и использовать для своих задач, мы поставляем готовый продукт заточенный для этих платформ, клиент при желании может купить сам железо, но той конфигурации которую мы ему скажем, там получается большой выигрыш.
Идеология простая как у Apple, там Macos не работает на любом хламе, есть вполне чёткие железки, но мы не стараемся замкнуть на себя.
Далее, мы поставляем документацию по ремонту СХД, любой может, как вы говорите «в любой деревне» сам починить, это не секрет, а Customer field replacement.
Если тех поддержка наша, то ремонт будет от нас, если нет, то от того, кто продаёт.
Опять же, обновления софта мы выдаём бесплатно, а решение проблем для клиента в рамках контракта.
Идеология простая как у Apple, там Macos не работает на любом хламе, есть вполне чёткие железки, но мы не стараемся замкнуть на себя.
Далее, мы поставляем документацию по ремонту СХД, любой может, как вы говорите «в любой деревне» сам починить, это не секрет, а Customer field replacement.
Если тех поддержка наша, то ремонт будет от нас, если нет, то от того, кто продаёт.
Опять же, обновления софта мы выдаём бесплатно, а решение проблем для клиента в рамках контракта.
Первая история, конечно, поучительна, да выводы сделаны какие-то обратные. Стоит учитывать, что передача вопросов пуско-наладки, саппорта производителю — это в чистом виде «аутсорс рисков», а то, что у их инженера не будет достаточной компетенции — это проблема их целиком и полностью. Допустим, инженер вендора Коля сжёг бы СХД в этой истории, кто бы за нее платил? Ответ простой — вендор её бы и менял за свой счёт (или попал бы на деньги авторизованный сервисный центр, но так или иначе компания-заказчик не рискует). Это не отменяет того, что Петя получил бы по шапке и мог вообще потерять работу, но это другая история. А вот если бы Петя сам делал пуско-наладочные работы с сжёг систему, кто бы платил за человеческий фактор и недостаточность информации в документации? Платила бы компания-заказчик, потому что с Пети, даже если он материально-ответственный, брать в общем-то и нечего.
С этой точки зрения в общем-то и не важно, каждый джампер наизусть успел выучить Петя или не каждый, главное — чтоб в своей работе разбирался, а пуско-наладкой пусть занимается производитель, ну а если уже такая СХД, что весит как «детёныш лесного слона» и требует трёхфазного питании — это уже совсем Hi-End, так тем более не стоит ему лезть туда лишний раз.
На мой взгляд, эту проблему отечественной продукции можно лишь созданием партнерских сервисных центров, самообучением «Как выжить при SLA, равном 4 часа» и т.д., а никак не сетованием на недостаток компетенций у наших родных инженеров, тем более что такое утверждение совсем несправедливо: и FIO пользоваться умеют, и TB от TiB отличают, и объяснять не надо, что при паттерне нагрузки 4K Random read 100% и 4K Random RW 60/40 при идентичном наборе дисков и конфигурации железа на одни и те же IOPS'ы рассчитывать не стоит.
Другой вопрос: что имеется ввиду под разными RAID'ами? Сами RAID'ы-то те же, могут отличаться алгоритмы расчёта четности, а вот как организовать группы — это даже не политика вендоров, а опыт пресейл-инженеров и самих инженеров. Функционал опять же типовой: у кого-то что-то лучше реализовано, у кого-то хуже, но классический набор: снэпшоты, дедупликация, компрессия, тиринг, локальная/удаленная синхронная/асинхронная репликация — всё это значит у всех вендоров одно и то же, и при включении компрессии пользователь получает компрессию, а вовсе не дизастер рекавери сайд из воздуха.
Кстати, про «мифы производителей СХД». Не знаю, по-моему, никаких секретов и нет, все знают, что в современных СХД используется самое обычное серверное железо, да, с vendor lock'ом, но вовсе никакой магии — любой СХД по сути комплект правильного железа с хорошо написанной софтовой управлялкой. А вот что интересно — наши разработчики «балуются PCIe»… хм… позвольте полюбопытствовать, о ком и о чем речь?
С этой точки зрения в общем-то и не важно, каждый джампер наизусть успел выучить Петя или не каждый, главное — чтоб в своей работе разбирался, а пуско-наладкой пусть занимается производитель, ну а если уже такая СХД, что весит как «детёныш лесного слона» и требует трёхфазного питании — это уже совсем Hi-End, так тем более не стоит ему лезть туда лишний раз.
На мой взгляд, эту проблему отечественной продукции можно лишь созданием партнерских сервисных центров, самообучением «Как выжить при SLA, равном 4 часа» и т.д., а никак не сетованием на недостаток компетенций у наших родных инженеров, тем более что такое утверждение совсем несправедливо: и FIO пользоваться умеют, и TB от TiB отличают, и объяснять не надо, что при паттерне нагрузки 4K Random read 100% и 4K Random RW 60/40 при идентичном наборе дисков и конфигурации железа на одни и те же IOPS'ы рассчитывать не стоит.
Другой вопрос: что имеется ввиду под разными RAID'ами? Сами RAID'ы-то те же, могут отличаться алгоритмы расчёта четности, а вот как организовать группы — это даже не политика вендоров, а опыт пресейл-инженеров и самих инженеров. Функционал опять же типовой: у кого-то что-то лучше реализовано, у кого-то хуже, но классический набор: снэпшоты, дедупликация, компрессия, тиринг, локальная/удаленная синхронная/асинхронная репликация — всё это значит у всех вендоров одно и то же, и при включении компрессии пользователь получает компрессию, а вовсе не дизастер рекавери сайд из воздуха.
Кстати, про «мифы производителей СХД». Не знаю, по-моему, никаких секретов и нет, все знают, что в современных СХД используется самое обычное серверное железо, да, с vendor lock'ом, но вовсе никакой магии — любой СХД по сути комплект правильного железа с хорошо написанной софтовой управлялкой. А вот что интересно — наши разработчики «балуются PCIe»… хм… позвольте полюбопытствовать, о ком и о чем речь?
История взята также с оглядкой на то, как вендор готовит инженеров, вывод простой, готовить он их не умеет, у нас есть опыт работы зарубежом и сравнить не трудно, у нас бизнес(продажи) везде управляют всем и даже производством, за рубежом бизнес никогда не управляет производством, он подсказывает в лучшем случае, так как людей в продажах поменять проще, чем людей в производстве. Примеры когда бизнес начинает управлять производством масса на западе и большинство их них плачевно заканчивают.
Подготовка инженеров у вендора оправдана тем, что есть такие моменты, которые нельзя передать партнёрам, но подготовка дорогое удовольствие и в «кризис» тем более, поэтому СХД запускают плохо подготовленные люди.
Теперь по поводу рисков для заказчика, они есть и серьёзные, так как у клиента нет выбора, его заставляют купить то, что он не хочет или ему не нужно, а если ИТ директор заплатил уже деньги владельца компании за продукт СХД, то вернуть их не просто, страдает во-первых сам клиент, так как ему уже нужно иметь СХД, слезть с «иглы» тяжело, опять страдает авторитет самого директора или человека принимающего решение.
Да, именно, партнёрские сервис-центры, только на базе отечественных решений, которые смогут сделать конкуренцию и подвинуть тех, кто привык ничего не делать — западные фирмы.
RAID мы описывали в предыдущей статье. Главная задача — обеспечить и гарантировать сохранность данных, что мы и делаем при тестировании у клиента.
Про мифы СХД от западных вендоров не все знают, практика показывает, что клиенты этого не понимают вовсе.
PCIe коммутаторы сейчас начинают производить многие, например для передачи данных эмулируя NTB, так как это даёт низкий latency.
Подготовка инженеров у вендора оправдана тем, что есть такие моменты, которые нельзя передать партнёрам, но подготовка дорогое удовольствие и в «кризис» тем более, поэтому СХД запускают плохо подготовленные люди.
Теперь по поводу рисков для заказчика, они есть и серьёзные, так как у клиента нет выбора, его заставляют купить то, что он не хочет или ему не нужно, а если ИТ директор заплатил уже деньги владельца компании за продукт СХД, то вернуть их не просто, страдает во-первых сам клиент, так как ему уже нужно иметь СХД, слезть с «иглы» тяжело, опять страдает авторитет самого директора или человека принимающего решение.
Да, именно, партнёрские сервис-центры, только на базе отечественных решений, которые смогут сделать конкуренцию и подвинуть тех, кто привык ничего не делать — западные фирмы.
RAID мы описывали в предыдущей статье. Главная задача — обеспечить и гарантировать сохранность данных, что мы и делаем при тестировании у клиента.
Про мифы СХД от западных вендоров не все знают, практика показывает, что клиенты этого не понимают вовсе.
PCIe коммутаторы сейчас начинают производить многие, например для передачи данных эмулируя NTB, так как это даёт низкий latency.
Не совсем уловил Вашу логику: зарубежная продукция лучше, потому что там бизнес не управляет производством, но тем не менее зарубежные вендоры хуже, потому что в России бизнес управляется производством, что неправильно. Или что имеется ввиду?
По поводу рисков: как всё-таки перекликается Ваша история с рисками? Система поставлена исправная, если бы инженер вендора в процессе пуско-наладочных работ сломал её, вендор замену произвел бы самостоятельно без участия заказчика. Развернули в один день. Зачем её возвращать было бы? Качество подготовки инженера вендора — головная боль вендора, так или иначе заказчик должен получить рабочую систему и он её получит по условиям договора поставки. Другая беда — если заказчик покупает компоненты, сам на неё накатывает SDS, и потом оказывается, что он ошибся в выборе компонентов, что в платформе диски U.2, а он закупил по ошибке PCIe x4, что карты Emulex не поддерживаются, нужно менять на Qlogic. И вот в этом случае идет IT-директор к владельцу бить челом, что недозакупили, надо ещё потратиться, и получает по шапке, почему сразу не заложили в стоимость. Потом спустя неделю-две в лучшем случае (а если не те NVMe купили, так здравствуйте 8 недель поставки), когда все компоненты заменены на нужные, начинают разворачивать, выясняется, что что-то недотестировали, не выловили, а статистики и мощностей вендора, чтобы быстро дыру залатать, не хватает, или вендору в принципе пофигу — такие тоже бывают. Эти риски гораздо реальнее, чем неопытный инженер вендора. А вот затраты на официальную поддержку — это не риски, это бюджетируемые расходы, которые получаются оправданы.
По поводу рисков: как всё-таки перекликается Ваша история с рисками? Система поставлена исправная, если бы инженер вендора в процессе пуско-наладочных работ сломал её, вендор замену произвел бы самостоятельно без участия заказчика. Развернули в один день. Зачем её возвращать было бы? Качество подготовки инженера вендора — головная боль вендора, так или иначе заказчик должен получить рабочую систему и он её получит по условиям договора поставки. Другая беда — если заказчик покупает компоненты, сам на неё накатывает SDS, и потом оказывается, что он ошибся в выборе компонентов, что в платформе диски U.2, а он закупил по ошибке PCIe x4, что карты Emulex не поддерживаются, нужно менять на Qlogic. И вот в этом случае идет IT-директор к владельцу бить челом, что недозакупили, надо ещё потратиться, и получает по шапке, почему сразу не заложили в стоимость. Потом спустя неделю-две в лучшем случае (а если не те NVMe купили, так здравствуйте 8 недель поставки), когда все компоненты заменены на нужные, начинают разворачивать, выясняется, что что-то недотестировали, не выловили, а статистики и мощностей вендора, чтобы быстро дыру залатать, не хватает, или вендору в принципе пофигу — такие тоже бывают. Эти риски гораздо реальнее, чем неопытный инженер вендора. А вот затраты на официальную поддержку — это не риски, это бюджетируемые расходы, которые получаются оправданы.
Мы не SDS, мы сертифицировали ряд конфигураций «железа», поэтому клиент получает готовую конфигурацию, которую он может купить сам или у нас. Весь цикл — продажа, постпродажная поддержка, техническое обслуживание Onsite И Remote — всё у нас есть и мы оказываем все услуги.
SDS не может быть в принципе на наш взгляд, так как невозможно сделать ряд функций СХД для любого «железа».
SDS не может быть в принципе на наш взгляд, так как невозможно сделать ряд функций СХД для любого «железа».
Как можно сказать, что у нас бизнес управляет производством, у них — не управляет? Может я неверно понимаю, но по собственному опыту всё в точности наоборот: да, не менеджеры по продажам диктуют, что должна производить компания, но производство отталкивается всегда от потребностей рынка, а также от того, что могло бы помочь заказчику решить его «боль», канал продаж выстраивается из соображений, чтобы заказчик мог получить нужный ему продукт из разных источников, развитая инфраструктура постпродажи, кросс-сейлы, апсейлы — всё это разрабатывается да, для денег, но и для того, чтобы решить проблемы заказчика, а не создать их.
И ровно обратная ситуация у нас — «бизнес, управляющий производством», когда человек придумал какую-то на его взгляд killer-фичу, придумал, почему она кровь из носа необходима на рынке и, не разбираясь в структуре рынка, не изучая конкурентов, посылая нафиг реальные потребности заказчика, идет напрямую к заказчикам, партнерам. Это так не работает.
Даже на банальном примере: допустим, я — системный интегратор. Для того, чтобы мне развернуть любой сложности IT-инфраструктуру компании, мне достаточно 2-3 контракта с дистрибьюторами, и всё. При ограниченном количестве поставщиков нарастить у каждого объемы до получения отсрочек по платежам не проблема, и работай в удовольствие. И таких системных интеграторов — тысячи, каждый в чем-то по-своему хорош. Но как только дело касается российской продукции, будь то софт или железяка, мне надо идти напрямую к производителю или к его партнеру, который для меня конкурент, полгода бодаться с их юристами, чтобы получить более-менее вменяемый контракт, за это время производитель 50 раз поменяет ценовую политику, раз 10 отложит релиз нового софта, выявит какие-нибудь супер-баги, которые надо срочно пофиксить, и так далее и тому подобное. И естественно, если я с ним иду в единственный проект, на какие-то отсрочки по платежам я могу не рассчитывать, а продукт априори не будет универсальным, чтобы его везде можно было ставить. Разве это можно назвать «продажами, которые управляют производством»?
Ну или иначе, есть небезызвестные процессоры американского производства, которые я могу купить в любой IT-компании: у любого дистрибьютора, у любого интегратора и в любом розничном магазине. Материнские платы для них делают и сами они, и все остальные: хочешь — сам рисуй, хочешь — купи референсные чертежи и печатай. Другая сторона медали — наши отечественные процессоры, не будем называть: их я могу купить только у двух-трёх компаний, каждая из которых является сама системным интегратором и с радостью пойдет к моему же заказчику, а если и не пойдет, то будет руки мне выкручивать, т.к. обладает N-ным эксклюзивом на рынке. Вроде и хочется помочь отчизне, а вот зачем мне это надо, если это даже производителю нафиг не нужно?
И ровно обратная ситуация у нас — «бизнес, управляющий производством», когда человек придумал какую-то на его взгляд killer-фичу, придумал, почему она кровь из носа необходима на рынке и, не разбираясь в структуре рынка, не изучая конкурентов, посылая нафиг реальные потребности заказчика, идет напрямую к заказчикам, партнерам. Это так не работает.
Даже на банальном примере: допустим, я — системный интегратор. Для того, чтобы мне развернуть любой сложности IT-инфраструктуру компании, мне достаточно 2-3 контракта с дистрибьюторами, и всё. При ограниченном количестве поставщиков нарастить у каждого объемы до получения отсрочек по платежам не проблема, и работай в удовольствие. И таких системных интеграторов — тысячи, каждый в чем-то по-своему хорош. Но как только дело касается российской продукции, будь то софт или железяка, мне надо идти напрямую к производителю или к его партнеру, который для меня конкурент, полгода бодаться с их юристами, чтобы получить более-менее вменяемый контракт, за это время производитель 50 раз поменяет ценовую политику, раз 10 отложит релиз нового софта, выявит какие-нибудь супер-баги, которые надо срочно пофиксить, и так далее и тому подобное. И естественно, если я с ним иду в единственный проект, на какие-то отсрочки по платежам я могу не рассчитывать, а продукт априори не будет универсальным, чтобы его везде можно было ставить. Разве это можно назвать «продажами, которые управляют производством»?
Ну или иначе, есть небезызвестные процессоры американского производства, которые я могу купить в любой IT-компании: у любого дистрибьютора, у любого интегратора и в любом розничном магазине. Материнские платы для них делают и сами они, и все остальные: хочешь — сам рисуй, хочешь — купи референсные чертежи и печатай. Другая сторона медали — наши отечественные процессоры, не будем называть: их я могу купить только у двух-трёх компаний, каждая из которых является сама системным интегратором и с радостью пойдет к моему же заказчику, а если и не пойдет, то будет руки мне выкручивать, т.к. обладает N-ным эксклюзивом на рынке. Вроде и хочется помочь отчизне, а вот зачем мне это надо, если это даже производителю нафиг не нужно?
Частично согласен, но в общем и целом у нас возможно производство СХД, по той причине, что у наш эксклюзив — программное обеспечение и экмпертиза на рынке, мы можем решать проблемы клиентов лучше чем другие вендоры, есть готовые сценарии для СУБД, виртуализации и т.д. Мы их готовим сейчас и скоро опубликуем, т.е. мы видим наше преимущество в use case'ах для применения СХД, чтобы показать реальную выгоду для бизнеса. Как правило западные вендоры СХД не предлагают реальных сценариев для программного обеспечения (SAP, Oracle и т.д.), они просто пишут про настройки для интеграции, но нет реального Value. Мы это знаем и это pain point.
Наша цель сделать широкую доступность нашего продукта для потребителей на рынке.
Далее, мы предлагаем решить именно задачу клиента, например: ЦОД с disaster recovery кластера ESXi VMWare и репликацией, обеспечив масштабируемость и работу СХД системы как минимум на 7 лет. Выгоду можно легко посчитать, мы не выламываем руки для апгрейда СХД как это делают другие вендоры.
Для интеграторов вполне очевидная выгода — свободная лицензионная политика нашего СХД.
Отечественные процессоры — это проблема рынка, у нас привыкли делать эксклюзив.
По примеру Китая, там есть ряд крупных вендоров, которые делают свои чипы сами, их не более 3, все остальные, а это сотни компаний в КИтае, делают системы на базе этих чипов. Поэтому делать бизнес можно с отечественными процессорами, если только у людей в голове будет понимание как это делать, но пока этого нет к сожалению, у них ограниченный взгляд. В Китае задача — захватить рынок в мире, а у наших производителей видимо другие задачи, если они вообще есть :)
Наша цель сделать широкую доступность нашего продукта для потребителей на рынке.
Далее, мы предлагаем решить именно задачу клиента, например: ЦОД с disaster recovery кластера ESXi VMWare и репликацией, обеспечив масштабируемость и работу СХД системы как минимум на 7 лет. Выгоду можно легко посчитать, мы не выламываем руки для апгрейда СХД как это делают другие вендоры.
Для интеграторов вполне очевидная выгода — свободная лицензионная политика нашего СХД.
Отечественные процессоры — это проблема рынка, у нас привыкли делать эксклюзив.
По примеру Китая, там есть ряд крупных вендоров, которые делают свои чипы сами, их не более 3, все остальные, а это сотни компаний в КИтае, делают системы на базе этих чипов. Поэтому делать бизнес можно с отечественными процессорами, если только у людей в голове будет понимание как это делать, но пока этого нет к сожалению, у них ограниченный взгляд. В Китае задача — захватить рынок в мире, а у наших производителей видимо другие задачи, если они вообще есть :)
Sign up to leave a comment.
Один день из жизни закаленного админа или рассказ о том как приручить СХД