Есть два типа сертификации:
односторонняя, когда нашими силами или нашими партнерами проводится тестирование аппаратного обеспечения.
Это оборудование попадает в HCL и поддерживается нами и партнерами.
HCL можно попросить, написав на info@raidixstorage.com
двухсторонняя, когда вендор выполняет тестирование нашего ПО и распространяет его без нашего участи через свой канал
Второй вариант с компаниями из первого эшелона возможен только под крупные проекты, из второго эшелона подобные отношения сложены, например, с AIC.
Добрый день!
Если есть желание, напишем статью про реализацию полиномиальный арифметики.
Как я писал выше, с NVDIMM пока не работаем, тк полноценная поддержка со всех сторон (модули, BIOS MB, нормальный SDK, OS) пока не была нами обнаружена
Пока что требуется использовать дополнительные модули бесперебойного питания. Внешние или внутренние.
Но ничего безумно сложного в реализации я не вижу При благоприятном стечение обстоятельств будет поддержка модулей, использующих суперконденсаторы.
При неинициализированном массиве парити не соответствуют данным на информационных стрипах. Поэтому каждая запись в несколько килобайт требует чтение всего страйпа, изменения контрольных сумм и запись измененного стрипа и партии на диски.
В итоге не получаем никакого распараллеливания.
При инициализированном массиве, мы имеем парити, соответствующую данным на стрипах с информационными полосами.
Поэтому, при random write читаем стрип с изменяемыми данными и парити, парити пересчитываем и все записываем обратно. Получаем распараллеливание.
Конечно, при последовательных обращениях такой проблемы нет.
Также кэш на запись может помочь.
Всех тестов с идеальными настройками не показали, но, думаю будет цикл статей по бэнчмаркингу СХД.
Кэш в RAM, поэтому одноконтроллерная система, при неправильном проектировании, может потерять грязные сегменты кэша.
Сейчас все больше компаний производит NVDIMM, но нормальных SDK и безбажной поддержки в BIOS нет
Как только, появятся — будет поддержка в RAIDIX
Поэтому для защиты от сбоев:
-использовать внешние или внутренние SPS-модули, по одному на контроллер. При разрядке SPS, ПО получит сигнал и сбросит грязный кэш.
-использовать двухконтроллерную конфигурацию (например, на базе Supermicro SBB)
В DC режиме грязные сегменты кэша зеркалируются друг между контролерами и без проблем переживает любой вид отказа. Фэйловер менее секунды.
Обновление, опять же будет только на отказоустойчивый конфигурации не требовать простоя.
Чаще всего, это скрипт, делающий бэкап текущей конфигурации и выполняющий установку rpm.
Причина классического подхода — первоначальная задача, для которой cow и row в лоб не подходят. Вы, наверняка, знаете, что NetApp не позиционирует свои FAS-based продукты для HPC и M&E. Для этого они используют E-Series, бывший LSI. Мы здесь не для того, чтобы поливать грязью технологии конкурента, но и слепо копировать ничего не хотим. Мы думаем, что делать. Есть разные варианты. Например, применять подход, похожий на используемый в LSFS, cow, row и тд
Сейчас делаем man-to-many rebuild, уходя от классической схемы массивов. Затем будем больше оптимизироваться под flash. Тогда остро и встанет вопрос борьбы с write amplification, flash endurance.
Тк эта статья популярна, будет свой блог )
Вы в Москве? RAIDIX в СПб. Но мы можем как нибудь встретится и попить кофе. Очень интересно послушать про реальный опыт использования Lustre для Media and Entertainment.
Это все-таки решения для другого класса задач — хранение большого количества неструктурированных редкоизменяемых данных.
RAIDIX изначально разрабатывался как Active Storage.
Но на холодные данные тоже смотрим. Реализуем ScaleOut NAS и будем планировать объектный доступ.
Дали бы ссылочку на источник фотографий.
Возможно, кто-то прочитал бы внимательнее текст.
А то вон что автор пишет:
«На объекте действует режим высокой секретности. К нашему прибытию в каждом очередном помещении выключались мониторы, переворачивались лицом вниз инструкции. Часть аппаратуры было запрещено фотографировать, другая часть и вовсе была закрыта чехлами с печатью. Выключались даже те мониторы, на которых кроме пустого окна с парой цифр больше ничего не было. Если на какой-то фотографии ниже вам что-то увидится на экране монитора — это коллаж конечно же, нарисованный на скорую руку. На больших же настенный экранах специально для нас запускался демонстрационный ролик, специально созданный для нас, чтобы показать как примерно функционирует РЛС.»
Спасибо за совет.
А как по вашему мнению стоит управлять инфраструктурой-информацией о системном и прикладном ПО, установленном на ландшафтах тестирования, эксплуатации? И если системное ПО не столько важно для разработчиков, то часто информация о версии сервера приложений и установленных апдейтах, версии java-машины или .net-фреймворка играет важную роль при принятии решения о использовании технологий при разработке(или необходимости изменений в прикладном ПО).
А как быть, если разработка ведется на основе какой-либо платформы, например Microsoft Sharepoint? Результирующим продуктом будут не только приложения но и набор настроек платформы. Есть ли какие-либо рекомендации по управлению конфигурациями серверов приложений и прочего. Как в этом случае выделять baselines. Как быть если для работы определенного приложения нужна определенная настройка?
Плачет то он плачет, но я уверен, что автор топика поленится пойти написать заявление. Если милиция не будет завалена жалобами, то через пару месяцев каждому будет приходить по десятку подобных спам-сообщений.
Коврики взяты для примера, как первое, что пришло в голову. Но раз Вам не понравилось сравнение, попробую аргументировать. (!!! Внимание!!! Всем остальным воспринимать, как шутку)
1) Мерседес во все комплектации автомобилей (за исключением грузовиков) кладёт оригинальные коврики. В других марках(Пример Мицубиси Лансер) можно не заказывать оригинальные коврики, для экономии бюджета или с целью установки своих.
2)Любой автолюбитель может запросто поменять коврики. Можно иметь несколько ковриков для различных целей(велюровые для города и сухой погоды, резиновые для зимы) Можно менять, можно класть несколько ковриков друг на друга.
3)Коврики производят множество организаций. Есть универсальные, есть подходящие для конкретной марки.
4)Оригинальные велюровые мерседесовские коврики через какое то время загрязняются и вычищать их большая проблема(Жесткий и глубокий ворс) и мойщики автомобилей, коим достаётся это нелёгкое занятие, считают, что нужно заменить их на резиновые, коим грязь нипочём.
А файловая система у вас какая? Смотрели во время работы тестов iostat?
односторонняя, когда нашими силами или нашими партнерами проводится тестирование аппаратного обеспечения.
Это оборудование попадает в HCL и поддерживается нами и партнерами.
HCL можно попросить, написав на info@raidixstorage.com
двухсторонняя, когда вендор выполняет тестирование нашего ПО и распространяет его без нашего участи через свой канал
Второй вариант с компаниями из первого эшелона возможен только под крупные проекты, из второго эшелона подобные отношения сложены, например, с AIC.
Если есть желание, напишем статью про реализацию полиномиальный арифметики.
Как я писал выше, с NVDIMM пока не работаем, тк полноценная поддержка со всех сторон (модули, BIOS MB, нормальный SDK, OS) пока не была нами обнаружена
Пока что требуется использовать дополнительные модули бесперебойного питания. Внешние или внутренние.
Но ничего безумно сложного в реализации я не вижу При благоприятном стечение обстоятельств будет поддержка модулей, использующих суперконденсаторы.
В итоге не получаем никакого распараллеливания.
При инициализированном массиве, мы имеем парити, соответствующую данным на стрипах с информационными полосами.
Поэтому, при random write читаем стрип с изменяемыми данными и парити, парити пересчитываем и все записываем обратно. Получаем распараллеливание.
Конечно, при последовательных обращениях такой проблемы нет.
Также кэш на запись может помочь.
Всех тестов с идеальными настройками не показали, но, думаю будет цикл статей по бэнчмаркингу СХД.
Сейчас все больше компаний производит NVDIMM, но нормальных SDK и безбажной поддержки в BIOS нет
Как только, появятся — будет поддержка в RAIDIX
Поэтому для защиты от сбоев:
-использовать внешние или внутренние SPS-модули, по одному на контроллер. При разрядке SPS, ПО получит сигнал и сбросит грязный кэш.
-использовать двухконтроллерную конфигурацию (например, на базе Supermicro SBB)
В DC режиме грязные сегменты кэша зеркалируются друг между контролерами и без проблем переживает любой вид отказа. Фэйловер менее секунды.
Обновление, опять же будет только на отказоустойчивый конфигурации не требовать простоя.
Чаще всего, это скрипт, делающий бэкап текущей конфигурации и выполняющий установку rpm.
www.arppsoft.ru/
Сейчас делаем man-to-many rebuild, уходя от классической схемы массивов. Затем будем больше оптимизироваться под flash. Тогда остро и встанет вопрос борьбы с write amplification, flash endurance.
Тк эта статья популярна, будет свой блог )
RAIDIX изначально разрабатывался как Active Storage.
Но на холодные данные тоже смотрим. Реализуем ScaleOut NAS и будем планировать объектный доступ.
Возможно, кто-то прочитал бы внимательнее текст.
А то вон что автор пишет:
«На объекте действует режим высокой секретности. К нашему прибытию в каждом очередном помещении выключались мониторы, переворачивались лицом вниз инструкции. Часть аппаратуры было запрещено фотографировать, другая часть и вовсе была закрыта чехлами с печатью. Выключались даже те мониторы, на которых кроме пустого окна с парой цифр больше ничего не было. Если на какой-то фотографии ниже вам что-то увидится на экране монитора — это коллаж конечно же, нарисованный на скорую руку. На больших же настенный экранах специально для нас запускался демонстрационный ролик, специально созданный для нас, чтобы показать как примерно функционирует РЛС.»
А как по вашему мнению стоит управлять инфраструктурой-информацией о системном и прикладном ПО, установленном на ландшафтах тестирования, эксплуатации? И если системное ПО не столько важно для разработчиков, то часто информация о версии сервера приложений и установленных апдейтах, версии java-машины или .net-фреймворка играет важную роль при принятии решения о использовании технологий при разработке(или необходимости изменений в прикладном ПО).
oldmann.livejournal.com/125252.html
1) Мерседес во все комплектации автомобилей (за исключением грузовиков) кладёт оригинальные коврики. В других марках(Пример Мицубиси Лансер) можно не заказывать оригинальные коврики, для экономии бюджета или с целью установки своих.
2)Любой автолюбитель может запросто поменять коврики. Можно иметь несколько ковриков для различных целей(велюровые для города и сухой погоды, резиновые для зимы) Можно менять, можно класть несколько ковриков друг на друга.
3)Коврики производят множество организаций. Есть универсальные, есть подходящие для конкретной марки.
4)Оригинальные велюровые мерседесовские коврики через какое то время загрязняются и вычищать их большая проблема(Жесткий и глубокий ворс) и мойщики автомобилей, коим достаётся это нелёгкое занятие, считают, что нужно заменить их на резиновые, коим грязь нипочём.