Ленты имеют возможность размагничиваться и кассеты ломаться, на моей памяти есть десятки случаев когда магнитофоны портят кассеты, и важные бэкапы просто теряются, поэтому никуда не уйти в крупных компаниях от промежуточного хранения на дисках и лентах. VTL не просто хранит на диске, она сжимает и дедуплицирует и потом льет на ленту, Автор рекламирует Veam, а теорию подзабыл напрочь, как раз чтобы на ленте больше уместилось, софт резервного копирования может сначала быстро записать бэкап на диск VTL, ради этого VTL и создавалась, а потом уже сжатые и дедупилицированные данные лить на ленту.
Отличная тема!!! Рад, что система работает и справляется с нагрузкой. Опишите в цифирях, сколько IOPS обслуживает Ваша система хранения данных, будет очень интересно узнать нагрузку.
А то дремучие Exchange админы не верят, так смешно читать комменты некоторых товарищей, которые никогда кода не писали, а думают что за бугром поле чудес.
Мы не SDS, мы сертифицировали ряд конфигураций «железа», поэтому клиент получает готовую конфигурацию, которую он может купить сам или у нас. Весь цикл — продажа, постпродажная поддержка, техническое обслуживание Onsite И Remote — всё у нас есть и мы оказываем все услуги.
SDS не может быть в принципе на наш взгляд, так как невозможно сделать ряд функций СХД для любого «железа».
Частично согласен, но в общем и целом у нас возможно производство СХД, по той причине, что у наш эксклюзив — программное обеспечение и экмпертиза на рынке, мы можем решать проблемы клиентов лучше чем другие вендоры, есть готовые сценарии для СУБД, виртуализации и т.д. Мы их готовим сейчас и скоро опубликуем, т.е. мы видим наше преимущество в use case'ах для применения СХД, чтобы показать реальную выгоду для бизнеса. Как правило западные вендоры СХД не предлагают реальных сценариев для программного обеспечения (SAP, Oracle и т.д.), они просто пишут про настройки для интеграции, но нет реального Value. Мы это знаем и это pain point.
Наша цель сделать широкую доступность нашего продукта для потребителей на рынке.
Далее, мы предлагаем решить именно задачу клиента, например: ЦОД с disaster recovery кластера ESXi VMWare и репликацией, обеспечив масштабируемость и работу СХД системы как минимум на 7 лет. Выгоду можно легко посчитать, мы не выламываем руки для апгрейда СХД как это делают другие вендоры.
Для интеграторов вполне очевидная выгода — свободная лицензионная политика нашего СХД.
Отечественные процессоры — это проблема рынка, у нас привыкли делать эксклюзив.
По примеру Китая, там есть ряд крупных вендоров, которые делают свои чипы сами, их не более 3, все остальные, а это сотни компаний в КИтае, делают системы на базе этих чипов. Поэтому делать бизнес можно с отечественными процессорами, если только у людей в голове будет понимание как это делать, но пока этого нет к сожалению, у них ограниченный взгляд. В Китае задача — захватить рынок в мире, а у наших производителей видимо другие задачи, если они вообще есть :)
История взята также с оглядкой на то, как вендор готовит инженеров, вывод простой, готовить он их не умеет, у нас есть опыт работы зарубежом и сравнить не трудно, у нас бизнес(продажи) везде управляют всем и даже производством, за рубежом бизнес никогда не управляет производством, он подсказывает в лучшем случае, так как людей в продажах поменять проще, чем людей в производстве. Примеры когда бизнес начинает управлять производством масса на западе и большинство их них плачевно заканчивают.
Подготовка инженеров у вендора оправдана тем, что есть такие моменты, которые нельзя передать партнёрам, но подготовка дорогое удовольствие и в «кризис» тем более, поэтому СХД запускают плохо подготовленные люди.
Теперь по поводу рисков для заказчика, они есть и серьёзные, так как у клиента нет выбора, его заставляют купить то, что он не хочет или ему не нужно, а если ИТ директор заплатил уже деньги владельца компании за продукт СХД, то вернуть их не просто, страдает во-первых сам клиент, так как ему уже нужно иметь СХД, слезть с «иглы» тяжело, опять страдает авторитет самого директора или человека принимающего решение.
Да, именно, партнёрские сервис-центры, только на базе отечественных решений, которые смогут сделать конкуренцию и подвинуть тех, кто привык ничего не делать — западные фирмы.
RAID мы описывали в предыдущей статье. Главная задача — обеспечить и гарантировать сохранность данных, что мы и делаем при тестировании у клиента.
Про мифы СХД от западных вендоров не все знают, практика показывает, что клиенты этого не понимают вовсе.
PCIe коммутаторы сейчас начинают производить многие, например для передачи данных эмулируя NTB, так как это даёт низкий latency.
Вы конкретно напишите про что Вы дискутируете? я не понимаю суть Вашего вопроса. Какие 10 лет и вообще Вы о чём, в каком сложном Enterprise? Мы знаем все сложные Enterprise? Скажу Вам так, маркетинговая крышка и слова Enterprise призваны разделять решения на категории для привелигированных и всех остальных. А на практике High End у всех компаний не стоит тех денег за которые его продают. Может быть Вы не в курсе, но компании западные продают одно и тоже железо под маркой High End просто меняя ценник в 4 раза выше.
ПОтом внешний интерфейс в СХД не имеет никакого значения, вообще сравнивать СХД по внешнему интерфейсу доступа к данным не имеет смысла вообще, мы можем встроить любой интерфейс, просто FC все любят и многие ему доверяют на рынке, что вполне оправдано.
Согласен, нам это всё знакомо, решаем мы следующим образом, у нас сертфицировано 2 платформы сейчас, каждый может её купить сам и использовать для своих задач, мы поставляем готовый продукт заточенный для этих платформ, клиент при желании может купить сам железо, но той конфигурации которую мы ему скажем, там получается большой выигрыш.
Идеология простая как у Apple, там Macos не работает на любом хламе, есть вполне чёткие железки, но мы не стараемся замкнуть на себя.
Далее, мы поставляем документацию по ремонту СХД, любой может, как вы говорите «в любой деревне» сам починить, это не секрет, а Customer field replacement.
Если тех поддержка наша, то ремонт будет от нас, если нет, то от того, кто продаёт.
Опять же, обновления софта мы выдаём бесплатно, а решение проблем для клиента в рамках контракта.
Вы меня неверно поняли, во-первых я не против iscsi, он замечателен сам по себе, например не нужно разрабатывать сложное железо, а достаточно иметь сетевую карту и можно хоть на своём ноуте заниматься разработкой на базе iscsi.
Мне это нравится и это здорово, но СХД это не просто iscsi, СХД гораздо сложнее, если мы пытаемся решать сложные задачи и гарантировать надёжность данных.
Мы используем и поддерживаем iscsi тоже в своём СХД.
Для реальных задач всё-таки FC не уходит с рынка, так как сетевое оборудование Ethernet не может обеспечить надёжной доставки данных для серьёзных высоконагруженных задач, обслуживая мимоходом ещё сетевые запросы клиентов, MPLS и т.д. Но выделенные Ethernet сети думаю можно применять для задач SAN, но осторожно :)
Идея нашей статьи поддержать вообще создание и разработку отечественных СХД, если у нас будет больше компаний производителей, то мы только все выиграем от этого и сможем реально на рынке у нас сделать здоровую конкуренцию.
Я не против 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 групп.
Давайте договоримся что именно мы обсуждаем, если с точки зрения клиента и пользователя СХД, то предлагаю просто сравнить архитектуру, у нас о есть описание в предыдущей нашей статье и здесь storequant.ru/pdf/STOREQUANT_STORAGE_PRODUCT.pdf
Но я попробую привести ряд аргументов в свою пользу,
1) Наша система кэш-based, это означает, что мы пишем данные сначала в кэш, перед записью на диск, и отвечает клиенту о завершении IO после попадания данных в кэш. Причина простая — тем самым мы повышаем производительность.
2) Все операции в кэш должны быть сохранены на диск, в случае аппаратного сбоя и у нас есть операция gracefull shutdown, что означает сохранение всех данных в кэш на промежуточный диск в случае shutdown системы. Т.е. данные в RAM мы не теряем никогда, у нас есть батарея в составе СХД.
3) Далее все операции IO дублируются как минимум на второй контроллер в паре.
ПОэтому если один контроллер сломается, второй сразу будет доступен клиенту для доступа к данным на томе.
4) Мы поддерживаем до 1024 контроллеров в сумме. Каждый контроллер это шасси с дисками с горячей заменой, т.е. замена дисков в Online.
5) Каждый контроллер может объединяться в пару с любым контроллером (до 8 макс) и выполняется это программно, без физической коммутации.
Ceph — это программно определяемая распределенная файловая система. Мы говорим про блочный Storage, разница очень большая. Например при обновлении микрокода нам не нужно перезагружать контроллер СХД, мы не теряем 50% пропускной способности во время обновления как это делают 2-х контроллерные конфигурации подавляющего большинства СХД.
По поводу iSCSI, честно говоря это очень странный стандарт, дело в том, что FC к примеру был разработан специально как транспорт для SCSI, а также были придуманы коммутаторы и специальное оборудование на базе FPGA от CISCO и Brocade, чтобы создавать SAN.
Т.е. комитет T10/T11 NCITS состоящий из ряда базовых компаний в Штатах в этой области договорился развивать FC для нужд СХД и передачи данных.
С TCP/IP изначально было всё не так. Решили просто посадить SCSI туда и придумали RFC для iSCSI, который несёт массу накладных расходов, так как сетевые карты знать не знают о том, что они передают. В моём понимании iSCSI это очень экспериментальный стандарт.
Согласен, админу не нужно С++ знать, поэтому мы сделали ещё и Python :) Open-source много не умеет, например обновить код Opensource систему без остановки нельзя, а у нас можно, мы это специально делали. Потом есть архитектурные отличия нас от Opensource, в итоге получается что поддерживать OPensource, который много чего использует в Kernel сложно и дорого для компаний. Потом кто будет отвечать за СХД на Opensource, админ? Для этого есть компания вендор, в частности мы развиваем продукт и обеспечиваем maintenance, support и т.д. А кто обеспечит гарантию того, что данные не потеряют? Мы проводим серьёзные тесты, сейчас в нашем репозитарии около 500 тестов, которые обязательно должны пройти перед тем как мы выпустим очередной релиз своей СХД.
Не совсем понял ваше сравнение с 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.
Мы рассмотрели систему, которую Вы упоминаете и на сайте обнаружили фото СХД, где написано что это SAN Volume Controller. Исходя из этого и также заявленных характеристик которые мы прочитали, наши преимущества:
1) Наше решение полностью принадлежит нам, исходный код ПО полностью нашей разработки. Мы также выдаём его партнёрам и у нас есть ISV OEM предложение.
2) Мы масштабируемся более чем на 8 контроллеров, наш предел 1024 контроллера, причём они работают в единой СХД системе, т.е. все дисковые ресурсы доступны любому контроллеру.
3) В следствии масштабирования мы имеем кэш большего размера, на один контроллер это 1500 МБ при условии памяти типа DDR4. В итоге мы может даже построить СХД только на кэш памяти.
4) В следствии масштабирования мы также поддерживаем большее количество дисков — максимум 24576.
5) Важно, что в следствии большого масштаба до 1024 контроллеров, мы легко прокачиваем данные с большой скоростью по Backend и это позволяет нам масштабироваться.
6) Мы реально изолируем нагрузку на уровне портов, кэш памяти, чего не умеет IBM SVC. Об этом мы рассказали в статье, Рисунок 3. Это пожалуйста самая нужная фича для клиентов.
7) Мы реализовали свой протокол шины BackEnd и это нам позволяет абстрагироваться от адаптеров, т.е. от железа.
8) Мы поддерживаем все функции, включая thin provisioning, replication, snapshots (COW & physical). Пока нет Tiering, но скоро будет, помимо этого есть сжатие данных и дедупликация.
Судя по многим вопросам, у нас складывается мнение, что СХД воспринимается как железо, однако хочу отметить, что на 90% СХД — софт.
Это продиктовано экономикой — софт дешевле и быстрее делать и инвестировать в него выгоднее, чем в железо.
Мы ещё будем рассказывать про наши программные решения и готовим целый цикл статей.
В следующей статье мы подробно расскажем как выглядит СХД и рассмотрим массу конфигураций, данная статья имеет уклон в сторону разработчиков.
Статья готова и мы скоро её опубликуем.
Конечно, мы уже привели ссылку в статье где можно посмотреть базовую конфигурацию СХД, привожу ссылку ещё раз storequant.ru/pdf/STOREQUANT_STORAGE_PRODUCT.pdf
Безусловно есть hot swap, а также hot swap диски, в описании мы привели два базовых контроллера 1U и 2U.
Можно объединить до 1024 контроллеров, т.е. получается в максимальной комплектации Вы можете получить 1024 U или 2048 U.
В статье мы рассказываем базовые принципы объединения контроллеров в единый массив в составе одной СХД.
Мы сейчас формируем описание решений и скоро будут доступны все описания, Вы можете отправить нам запрос по почте указанную в контактах и мы вышлем вам адресно всю информацию. В статье мы привели ссылки на описание решений здесь storequant.ru/pdf/STOREQUANT_STORAGE_PRODUCT.pdf и здесь storequant.ru/pdf/ISV.pdf
Сложно отвечать на многогранный вопрос в комментариях, использование например FC HBA в нашем решении вызвано тем, что клиенты уже имеют инфраструктуру, но решение наше не зависит от FC HBA. FPGA про который я упоминаю относится к другой теме и я имею ввиду вполне конкретный продукт от одной американской фирмы, а также других фирм. Чтобы развернуто ответить на вопрос, прошу задавать их по почте в контактах на нашем сайте, мы сможем лично обсудить вопрос и я расскажу суть нашего решения.Прошу задавать вопросы в рамках нашего решения.
Ленты имеют возможность размагничиваться и кассеты ломаться, на моей памяти есть десятки случаев когда магнитофоны портят кассеты, и важные бэкапы просто теряются, поэтому никуда не уйти в крупных компаниях от промежуточного хранения на дисках и лентах. VTL не просто хранит на диске, она сжимает и дедуплицирует и потом льет на ленту, Автор рекламирует Veam, а теорию подзабыл напрочь, как раз чтобы на ленте больше уместилось, софт резервного копирования может сначала быстро записать бэкап на диск VTL, ради этого VTL и создавалась, а потом уже сжатые и дедупилицированные данные лить на ленту.
А то дремучие Exchange админы не верят, так смешно читать комменты некоторых товарищей, которые никогда кода не писали, а думают что за бугром поле чудес.
Спасибо.
SDS не может быть в принципе на наш взгляд, так как невозможно сделать ряд функций СХД для любого «железа».
Наша цель сделать широкую доступность нашего продукта для потребителей на рынке.
Далее, мы предлагаем решить именно задачу клиента, например: ЦОД с disaster recovery кластера ESXi VMWare и репликацией, обеспечив масштабируемость и работу СХД системы как минимум на 7 лет. Выгоду можно легко посчитать, мы не выламываем руки для апгрейда СХД как это делают другие вендоры.
Для интеграторов вполне очевидная выгода — свободная лицензионная политика нашего СХД.
Отечественные процессоры — это проблема рынка, у нас привыкли делать эксклюзив.
По примеру Китая, там есть ряд крупных вендоров, которые делают свои чипы сами, их не более 3, все остальные, а это сотни компаний в КИтае, делают системы на базе этих чипов. Поэтому делать бизнес можно с отечественными процессорами, если только у людей в голове будет понимание как это делать, но пока этого нет к сожалению, у них ограниченный взгляд. В Китае задача — захватить рынок в мире, а у наших производителей видимо другие задачи, если они вообще есть :)
Подготовка инженеров у вендора оправдана тем, что есть такие моменты, которые нельзя передать партнёрам, но подготовка дорогое удовольствие и в «кризис» тем более, поэтому СХД запускают плохо подготовленные люди.
Теперь по поводу рисков для заказчика, они есть и серьёзные, так как у клиента нет выбора, его заставляют купить то, что он не хочет или ему не нужно, а если ИТ директор заплатил уже деньги владельца компании за продукт СХД, то вернуть их не просто, страдает во-первых сам клиент, так как ему уже нужно иметь СХД, слезть с «иглы» тяжело, опять страдает авторитет самого директора или человека принимающего решение.
Да, именно, партнёрские сервис-центры, только на базе отечественных решений, которые смогут сделать конкуренцию и подвинуть тех, кто привык ничего не делать — западные фирмы.
RAID мы описывали в предыдущей статье. Главная задача — обеспечить и гарантировать сохранность данных, что мы и делаем при тестировании у клиента.
Про мифы СХД от западных вендоров не все знают, практика показывает, что клиенты этого не понимают вовсе.
PCIe коммутаторы сейчас начинают производить многие, например для передачи данных эмулируя NTB, так как это даёт низкий latency.
ПОтом внешний интерфейс в СХД не имеет никакого значения, вообще сравнивать СХД по внешнему интерфейсу доступа к данным не имеет смысла вообще, мы можем встроить любой интерфейс, просто FC все любят и многие ему доверяют на рынке, что вполне оправдано.
Идеология простая как у Apple, там Macos не работает на любом хламе, есть вполне чёткие железки, но мы не стараемся замкнуть на себя.
Далее, мы поставляем документацию по ремонту СХД, любой может, как вы говорите «в любой деревне» сам починить, это не секрет, а Customer field replacement.
Если тех поддержка наша, то ремонт будет от нас, если нет, то от того, кто продаёт.
Опять же, обновления софта мы выдаём бесплатно, а решение проблем для клиента в рамках контракта.
Мне это нравится и это здорово, но СХД это не просто iscsi, СХД гораздо сложнее, если мы пытаемся решать сложные задачи и гарантировать надёжность данных.
Мы используем и поддерживаем iscsi тоже в своём СХД.
Для реальных задач всё-таки FC не уходит с рынка, так как сетевое оборудование Ethernet не может обеспечить надёжной доставки данных для серьёзных высоконагруженных задач, обслуживая мимоходом ещё сетевые запросы клиентов, MPLS и т.д. Но выделенные Ethernet сети думаю можно применять для задач SAN, но осторожно :)
У iscsi есть ограничение, оно продиктовано тем, что он работает поверх сетевого протокола и поэтому есть накладные расходы за которые приходится расплачиваться скоростью.
Теперь по пунктам,
1) Мы не сетевой RAID, мы блочный сторадж и его можно применять для любых в том числе и в первую очередь для высоконагруженных систем.
Кэш у нас устроен таким образом, что он разбивается на партиции и каждая партиция может обслуживать свой VOlume, гарантируя производительность.
2) Батарея не наше ноухау, просто это решение задачи когда есть сбой электросети или нужно удалённо погасить СХД без потери данных
3) Мы не дублируем данные, мы используем RAID, каждый диск у нас адресуется в СХД любым контроллером, например в нашем СХД любой контроллер может прочитать данные на любом диске, даже если диск не находится в локальном шасси. Если диски в RAID распределены так, что они находятся в разных шасси, то получаем NSPOF. Можно выбирать разный уровень защиты — с одинарной четностью или двойной. Все конфигурации RAID у нас были в первой статье.
Вобще дублировать данные на NVMe дорогое удовольствие, учитывая их стоимость.
4) Нужно всё-таки представлять масштаб проблемы, мы заточены для Российского клиента, который выбирает не RAID, а надёжность, если клиент потеряет данные, то вобще нет смысла заниматься этой темой. Наш клиент — это Enterprise, где нужна высокая скорость и надёжность.
5) Мы используем Thin Provisioning и объединяем в Pool группы RAID, в одной RAID группе может быть до 256 дисков, в Pool можно объединить неограниченное количество RAID групп.
Но я попробую привести ряд аргументов в свою пользу,
1) Наша система кэш-based, это означает, что мы пишем данные сначала в кэш, перед записью на диск, и отвечает клиенту о завершении IO после попадания данных в кэш. Причина простая — тем самым мы повышаем производительность.
2) Все операции в кэш должны быть сохранены на диск, в случае аппаратного сбоя и у нас есть операция gracefull shutdown, что означает сохранение всех данных в кэш на промежуточный диск в случае shutdown системы. Т.е. данные в RAM мы не теряем никогда, у нас есть батарея в составе СХД.
3) Далее все операции IO дублируются как минимум на второй контроллер в паре.
ПОэтому если один контроллер сломается, второй сразу будет доступен клиенту для доступа к данным на томе.
4) Мы поддерживаем до 1024 контроллеров в сумме. Каждый контроллер это шасси с дисками с горячей заменой, т.е. замена дисков в Online.
5) Каждый контроллер может объединяться в пару с любым контроллером (до 8 макс) и выполняется это программно, без физической коммутации.
Т.е. комитет T10/T11 NCITS состоящий из ряда базовых компаний в Штатах в этой области договорился развивать FC для нужд СХД и передачи данных.
С TCP/IP изначально было всё не так. Решили просто посадить SCSI туда и придумали RFC для iSCSI, который несёт массу накладных расходов, так как сетевые карты знать не знают о том, что они передают. В моём понимании iSCSI это очень экспериментальный стандарт.
1) Наше решение полностью принадлежит нам, исходный код ПО полностью нашей разработки. Мы также выдаём его партнёрам и у нас есть ISV OEM предложение.
2) Мы масштабируемся более чем на 8 контроллеров, наш предел 1024 контроллера, причём они работают в единой СХД системе, т.е. все дисковые ресурсы доступны любому контроллеру.
3) В следствии масштабирования мы имеем кэш большего размера, на один контроллер это 1500 МБ при условии памяти типа DDR4. В итоге мы может даже построить СХД только на кэш памяти.
4) В следствии масштабирования мы также поддерживаем большее количество дисков — максимум 24576.
5) Важно, что в следствии большого масштаба до 1024 контроллеров, мы легко прокачиваем данные с большой скоростью по Backend и это позволяет нам масштабироваться.
6) Мы реально изолируем нагрузку на уровне портов, кэш памяти, чего не умеет IBM SVC. Об этом мы рассказали в статье, Рисунок 3. Это пожалуйста самая нужная фича для клиентов.
7) Мы реализовали свой протокол шины BackEnd и это нам позволяет абстрагироваться от адаптеров, т.е. от железа.
8) Мы поддерживаем все функции, включая thin provisioning, replication, snapshots (COW & physical). Пока нет Tiering, но скоро будет, помимо этого есть сжатие данных и дедупликация.
Судя по многим вопросам, у нас складывается мнение, что СХД воспринимается как железо, однако хочу отметить, что на 90% СХД — софт.
Это продиктовано экономикой — софт дешевле и быстрее делать и инвестировать в него выгоднее, чем в железо.
Мы ещё будем рассказывать про наши программные решения и готовим целый цикл статей.
Статья готова и мы скоро её опубликуем.
Безусловно есть hot swap, а также hot swap диски, в описании мы привели два базовых контроллера 1U и 2U.
Можно объединить до 1024 контроллеров, т.е. получается в максимальной комплектации Вы можете получить 1024 U или 2048 U.
В статье мы рассказываем базовые принципы объединения контроллеров в единый массив в составе одной СХД.