Два контроллера работают в режиме Active-Active с зеркалированием кэша. Каждый из них осуществляет операции ввода/вывода и работает со «своими» пулами.
Если вам так хочется реализовать подобное, то можно, например, подключать все эти пустующие места пользовательских ПК как сетевые папки к серверу резервного копирования. И уже правилами ПО бекапа перемещать/дублировать резервные копии.
Почему ни одна система резервного копирования не умеет использовать те немаленькие остатки дисков пользователей, когда из них вполне можно сделать распределенный массив для долгосрочных резервных копий?
Такой подход к организации резервного копирования будет подразумевать, что вам как администратору не очень важна сохранность и/или доступность копий. Понятно, что можно организационно и частично программно запретить пользователям расходовать место/удалять файлы/выключать ПК/..., но все же этот «носитель» не полностью подвластен администратору. Видимо, поэтому производители ПО резервного копирования не горят желанием реализовывать подобный функционал. И в качестве хранения бекапов предлагают использовать серверное оборудование (NAS, сервер, лента...)
Для нормальной работы ZFS действительно требуется ~10% незанятого места на пуле. Увы, такова особенность работы этой файловой системы. Причем, удаленные данные внутри LUNов средствами файловой системы хостов на уровне ZFS не удаляются (=не высвобождаются), о чем вам, по вашим словам, и сообщила техподдержка (compression enabled, sdelete). Поэтому грамотным решением в вашем случае является резервирование 10% пространства на пуле как не размеченное. Надеемся, ваш нынешний подрядчик так и поступил.
Что же касается высвобождения диска из пула, то вы же сами указали, что использовали RAID0 без всякой защиты. Разумеется, извлечение диска из массива приведет к потере данных. Чудес, увы, не будет.
Приведены тесты не только для 100% чтения, но и для симуляции реальных задач. И да, с 64КБ блоком производительность будет минимум в 16 раз ниже, чем с 4КБ. Это нормально.
вы уж тогда спеки с ценами покажите, иначе это просто голословные заявления. Или с конкурентами по list-price сравниваете? :)
Вы можете сравнить цены только либо через list price (что более или менее встречается в открытом доступе), либо придя к партнеру/дистрибьютеру с реальным проектом. По другому в IT мире никак.
И да, при отсутствии дедупа/компресси придётся брать qsan раза в 3 большего объёма, чем его конкуренты Tier 1, и тут ещё вопрос — как оно в итоге по цене то выйдет
Компрессия/дедуп будет скоро (~ 3-4 квартал) с обновлением прошивки. Что касается стоимости решения целиком, то по сравнению с конкурентами, где дедуп действительно эффективен и не приводит к катастрофическому падению производительности, Qsan оказывается в выигрыше.
Даже грубый подсчет для максимальных показателей 450K IOPS@4K даст нагрузку на порты менее 16Gbit/s, а для последовательного доступа 6000 MB/s ~48Gb/s. Что сильно меньше сумарной пропускной способности портов СХД в тесте (8x 16Gb/s).
По контроллерам, к сожалению, СХД не предоставляет отчета о нагрузке.
Да, конечно, контроллеры работают в режиме Active-Active. По другому в современных СХД, наверное, уже и не возможно.
FC доступен при помощи карт расширения (до 8 портов на контроллер).
Вы сравниваете поизводительность диска внутри сервера без прослойки в виде RAID и прочих уровней абстракции. При этом сервер имеет монопольный доступ к SSD. В СХД такой режим в принципе не возможен. Между ОС и диском есть немало элементов с ненулевыми задержками и ограниченными очередями. Плюс СХД предназначена для одновременной работы с многими хостами. И поэтому не в режиме работы «однин хост — один том» не удастся достичь пиковой производительности СХД.
Что касается latency в 2 мс, это просто мы условно ограничили показатель IOPS как некий «приемлимый». Если взглянуть на график, большая часть теста проходит с показателем не более 1 мс.
Наибольшей популярностью пользуется средняя серия XS3200 как наиболее оптимальная с точки зрения стоимости/производительности. Цены на этой площадке обсуждать вроде как не принято…
Два контроллера работают в режиме Active-Active с зеркалированием кэша. Каждый из них осуществляет операции ввода/вывода и работает со «своими» пулами.
Это вы откуда взяли? По вашему два контроллера работают по принципу «кто в лес, кто по дрова»?
Такой подход к организации резервного копирования будет подразумевать, что вам как администратору не очень важна сохранность и/или доступность копий. Понятно, что можно организационно и частично программно запретить пользователям расходовать место/удалять файлы/выключать ПК/..., но все же этот «носитель» не полностью подвластен администратору. Видимо, поэтому производители ПО резервного копирования не горят желанием реализовывать подобный функционал. И в качестве хранения бекапов предлагают использовать серверное оборудование (NAS, сервер, лента...)
Что же касается высвобождения диска из пула, то вы же сами указали, что использовали RAID0 без всякой защиты. Разумеется, извлечение диска из массива приведет к потере данных. Чудес, увы, не будет.
Вы можете сравнить цены только либо через list price (что более или менее встречается в открытом доступе), либо придя к партнеру/дистрибьютеру с реальным проектом. По другому в IT мире никак.
Компрессия/дедуп будет скоро (~ 3-4 квартал) с обновлением прошивки. Что касается стоимости решения целиком, то по сравнению с конкурентами, где дедуп действительно эффективен и не приводит к катастрофическому падению производительности, Qsan оказывается в выигрыше.
Даже грубый подсчет для максимальных показателей 450K IOPS@4K даст нагрузку на порты менее 16Gbit/s, а для последовательного доступа 6000 MB/s ~48Gb/s. Что сильно меньше сумарной пропускной способности портов СХД в тесте (8x 16Gb/s).
По контроллерам, к сожалению, СХД не предоставляет отчета о нагрузке.
FC доступен при помощи карт расширения (до 8 портов на контроллер).
Что касается latency в 2 мс, это просто мы условно ограничили показатель IOPS как некий «приемлимый». Если взглянуть на график, большая часть теста проходит с показателем не более 1 мс.