Comments 22
у меня вопрос в абзаце
Как устроен RAID в СХД StoreQuant Velocity Scale?
есть таблица
и в глаза бросилось
RAID60 2D+2P
если мне память не изменяет, то для организации raid 6 минималка по hdd 4
и если это обернуть все еще и нулевкой(60) то будет 8мь дисков, как вы делаете raid 60 на 4х дисках?
Как устроен RAID в СХД StoreQuant Velocity Scale?
есть таблица
и в глаза бросилось
RAID60 2D+2P
если мне память не изменяет, то для организации raid 6 минималка по hdd 4
и если это обернуть все еще и нулевкой(60) то будет 8мь дисков, как вы делаете raid 60 на 4х дисках?
здравствуйте, поясню, так как вариантов на рынке много, мы в названии RAID используем цифру 6 и цифру 0, подразумевается, что 6 — двойной контроль чётности, т.е. группа из 4 дисков имеет 2 диска под данные и два под контроль чётности, поэтому 2D + 2P, правильно сказать даже не диски, а ёмкость двух дисков тратится на паритет. Цифра 0 означает страйпинг, т.е. объёдинение ёмкости нескольких групп по 4 диска и соответственно объёдинение общей полезной ёмкости всех RAID-групп, но расчёт чётности происходит в рамках опять же каждой группы ( 4 диска) отдельно.
Ваше решение — это программно-аппаратный комплекс?
Да, это полноценная система с проверенной и надёжной аппаратной частью, описание конфигурации есть на нашем сайте и мы привели ссылку в статье storequant.ru/pdf/STOREQUANT_STORAGE_PRODUCT.pdf
Сейчас готовим также чисто софтверные решения, но о них позже мы расскажем.
Сейчас готовим также чисто софтверные решения, но о них позже мы расскажем.
В чём разница между Tatlin от Ядра и Вашим изделием?
Вопрос скорее всего не к нам, мы изложили свои технические данные в статье и также рассказали про нашу архитектуру, поэтому Вы можете взять все данные о нас и сравнить. Из тех игроков которые есть на нашем рынке мы представляем не open source завёрнутый в коммерческое решение, а проверенный годами алгоритмы и инновационную архитектуру. Наше решение полностью принадлежит нам и мы его развиваем, у нас нет заимствованных решений, как это часто бывает на рынке аналогичных решений. Но я не могу комментировать конкурентное решение, прошу задавать вопрос по нашей системе, я обязательно отвечу.
Кто для вас производит аппаратную платформу?
Мы производим свою плафторму, основа архитектуры x86, т.е. Intel. Сейчас есть планы портирования на Эльбрус архитектуру.
Контроллеры и адаптеры мы также проектируем сами, скоро выпустим статью на эту тему.
Если у вас есть вопросы, то вы можете написать нам через наш сайт запрос по почте указанной в контактах и мы адресно ответим.
Контроллеры и адаптеры мы также проектируем сами, скоро выпустим статью на эту тему.
Если у вас есть вопросы, то вы можете написать нам через наш сайт запрос по почте указанной в контактах и мы адресно ответим.
Партнёр полностью зависит от proprietary контроллеров на базе сложных и малодоступных процессорных технологий. Полученное решение в дальнейшем полностью зависит от жизненного цикла аппаратной платформы.
Что Вы имели ввиду?
мы не используем чужие FPGA, с встроенными программным обеспечением. Наше программное обеспечение практически не зависит от аппаратной платформы. Это принципиальное отличие, так как задача компаний которые предлагают свои контроллеры и FPGA на базе ARM — серьёзно привязать потребителей к своей аппаратной реализации. Наше мнение состоит в том, чтобы не привязываться к платформе. Использование FPGA сторонних вендоров не добавляет скорости и надёжности решения.
То есть этим вы хотите сказать, что используете контроллеры HBA от известных производителей, например, Marvell и пр.?
Нет, мы хотим сказать что разрабатывать такое решение на базе сложных FPGA долго и сложно искать кадров, а главное в условиях Российского рынка, поэтому для компаний, которые инвестируют в создание своих решений, наш вариант защищает инвестиции и значительно сокращает цикл разработки. Об этом мы и рассказываем в описании своей архитектуры.
А сами то что используете?
Мы используем надёжные решения, которые совместимы с инфраструктурой наших клиентов. Подробно можно узнать в описании нашей продуктовой линейки.
А главное не в том, что мы используем, а в том что получает клиент, а именно: он получает готовое решение, проверенное и протестированное.
А главное не в том, что мы используем, а в том что получает клиент, а именно: он получает готовое решение, проверенное и протестированное.
Ну вы просто советский партизан-герой на допросе у фашистов.
Сложно отвечать на многогранный вопрос в комментариях, использование например FC HBA в нашем решении вызвано тем, что клиенты уже имеют инфраструктуру, но решение наше не зависит от FC HBA. FPGA про который я упоминаю относится к другой теме и я имею ввиду вполне конкретный продукт от одной американской фирмы, а также других фирм. Чтобы развернуто ответить на вопрос, прошу задавать их по почте в контактах на нашем сайте, мы сможем лично обсудить вопрос и я расскажу суть нашего решения.Прошу задавать вопросы в рамках нашего решения.
А можно хотя бы одну картинку/фото, как выглядит ваша СХД в железе? Сколько юнитов занимает, насколько компоненты hot swap и т.п.? А то много текста, а дальше пусть работает воображение потенциальных клиентов?
Конечно, мы уже привели ссылку в статье где можно посмотреть базовую конфигурацию СХД, привожу ссылку ещё раз storequant.ru/pdf/STOREQUANT_STORAGE_PRODUCT.pdf
Безусловно есть hot swap, а также hot swap диски, в описании мы привели два базовых контроллера 1U и 2U.
Можно объединить до 1024 контроллеров, т.е. получается в максимальной комплектации Вы можете получить 1024 U или 2048 U.
В статье мы рассказываем базовые принципы объединения контроллеров в единый массив в составе одной СХД.
Безусловно есть hot swap, а также hot swap диски, в описании мы привели два базовых контроллера 1U и 2U.
Можно объединить до 1024 контроллеров, т.е. получается в максимальной комплектации Вы можете получить 1024 U или 2048 U.
В статье мы рассказываем базовые принципы объединения контроллеров в единый массив в составе одной СХД.
В следующей статье мы подробно расскажем как выглядит СХД и рассмотрим массу конфигураций, данная статья имеет уклон в сторону разработчиков.
Статья готова и мы скоро её опубликуем.
Статья готова и мы скоро её опубликуем.
Мы рассмотрели систему, которую Вы упоминаете и на сайте обнаружили фото СХД, где написано что это 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% СХД — софт.
Это продиктовано экономикой — софт дешевле и быстрее делать и инвестировать в него выгоднее, чем в железо.
Мы ещё будем рассказывать про наши программные решения и готовим целый цикл статей.
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% СХД — софт.
Это продиктовано экономикой — софт дешевле и быстрее делать и инвестировать в него выгоднее, чем в железо.
Мы ещё будем рассказывать про наши программные решения и готовим целый цикл статей.
У вас на сайте все ссылки ведут на # или на #contacts. Это не очень удобно
Мы сейчас формируем описание решений и скоро будут доступны все описания, Вы можете отправить нам запрос по почте указанную в контактах и мы вышлем вам адресно всю информацию. В статье мы привели ссылки на описание решений здесь storequant.ru/pdf/STOREQUANT_STORAGE_PRODUCT.pdf и здесь storequant.ru/pdf/ISV.pdf
Sign up to leave a comment.
Российские системы хранения данных от компании StoreQuant