И кстати, насчет Freestyle Libre. Сейчас уже выпускается 3 версия, со своим блютусом, которая вообще не требует внешних передатчиков.
Да, только на территории РФ они недоступны, и не ясно когда появятся.
xDrip+? К тому же, не встречал людей, кто сегодня использует один тип датчиков, завтра другой, послезавтра третий... Большинство получают в аптеке что назначено, и никаких метаний.
Да, только у xDrip+ есть огромное количество недостатков. Недоступность на iOS, отсутствие поддержки и внятной документации, нестабильная работа - в общем стандартный набор характеристик "народного" приложения.
А про поддержку разных типов датчиков шла речь не в контексте перехода между ними одним пользователем (что тоже происходит с определенной периодичностью), а с точки зрения обхвата максимально широкой аудитории.
Спасибо за уместные замечания, но эта статья задумывалась больше как информативная, нежели отчетная. Если кому-либо будет интересно продолжить работу в этом направлении, он может написать мне персонально, и я с радостью обменяюсь подробными наработками моей команды.
В целом я согласен с Вами, кроме последнего тезиса:
Это вы к чему? Вам любой изготовитель сервера хоть Windows хоть другие дистрибьютивы Linux поставит, если сами не можете, естественно абсолютно легально. Где найти «пиратскую» версию FreeNAS или Nas4Free и прочих бесплатных/открытых продуктов мне сложно даже представить.
Я рассматриваю данный продукт с точки зрения корпоративного рынка. И сравнивать его с бесплатными/открытыми решениями, неспособными предложить своим клиентам гарантию и соблюдение каких-либо SLA не вижу смысла.
Сравнивал с основными игроками full-flash решений enterprise-сегмента, перечисленными в отчете Gartner'а «Magic Quadrant for Solid-State Arrays» и представленными на российском рынке.
Любая СХД по сути своей является стоечным сервером. Основным отличием будет являться оптимизированный для хранения и обработки данных микрокод, имеющий тот или иной функционал, другой уровень вендорской поддержки и в некоторых случаях — проприетарные прошивки на дисках.
Решения типа «собрать на коленке и накатить пиратскую версию чего-то там» никогда не будут поддерживаться и обслуживаться производителем. И ни один специалист никогда не внедрит такое к себе в продуктив. Поэтому не вижу смысла тратить время на сравнение их цен.
Подобное оборудование продается исключительно по проектной схеме, т.е. каждый раз согласовывается индивидуальная скидка. Поэтому сравнивать"уличный" ценник просто некорректно.
В случае с разнесенным по ЦОДам приложением у нас всегда поулчается схема active-standby. Правильная настройка «Quorum Witness + активный узел кластера приложений» позволит избежать split-brain. Разница с другими аналогичными архитектурами в том, что в отличии от схемы active-standby, у нас не будет переключения на уровне системы хранения.
Для VSA нет обязательного условия иметь аппаратный RAID, т.к. ему через гипервизор презентуется дисковая емкость — в виде сырых дисков или раздела на vmfs datastore (виртуальный диск). Пользователь сам решает, что ему важнее – надежность или гибкость. Надо понимать, что при выходе из строя даже одного диска, без наличия аппаратного RAID, весь узел кластера (целая VSA) остановится. А если есть RAID, то узел продолжит работать.
Сценарий будет идентичным как и при падении узла. Система перейдет в статус Degrade, начнут сыпаться алерты, но кластер продолжит работу на базе доступного для приложения датацентра.
8) Консистетнтные для VMware and Hyper-V VMs и Microsoft VSS
Подробнее: в общем виде используется ПО Application Aware Snapshot Manager, которое ставится на внешний хост и управляет процессом создания консистентных снэпшотов (вернее его координирует, т.к. создание снэпшотов доступно и из консоли самой VSA). Поддерживаются ОС Windows Server 2012, Windows Server 2012 R2, Windows Server 2012 R2 Core, Windows Server 2008, 32-bit и 64-bit versions, vSphere (5.0, 5.1, 5.5 и 6.0). Перед созданием аппаратного снэпшота производятся необходимые действия по остановке (заморозке, снэпшоту) приложения (файловой системы).
7) (Тиринг) Работает в реальном времени блоками 256 KB
Чуть более подробно: можно определить два тира – 0 и 1. При подключении дискового пространства (датастора) в виртуальной машине VSA можно определить тип тира. По умолчанию все логические тома создаваемые внутри кластера используют оба тира. Все новые блоки всегда пишуться на тир 0 (пока там есть место), потом, по мере его заполнения, блоки начинают пистаться на тир 1. Все это время ведется т.н. heat map (карта горячих и холодных блоков на основе частоты обращений к них). Как только какие-то блоки становятся кандидатоми на миграцию, начинается миграция таких блоков. Для этого определяется равное кол-во холодных и горячих блоков и они перемещаются. Минимальный блок для миграции 256 КБ, общее кол-во таких блоков определяется динамически исходя из степени загрузки системы.
128TiB — это для одного LUN, лимитов для кластера не нахожу.
Не совсем согласен с вашим ответом.
Как таковых ограничений на размер тома нет. Есть лиценизонное ограние 50Тб на узел, в кластер собирается до 16 узлов, что на входе дает 800 Тб полезной емкости (до объединения в Network RAID).
Благодарю за оперативный ответ :)
Хочу добавить относительно StoreVirtual 3200 — продукт тоже крайне интерессный в плане переноса архитектуры SDS на аппаратную платформу. Коллеги обещали привезти его мне в демо до конца года. Как только получу на руки, то сразу напишу аналогичный обзор.
В данном случае возникает два уровня RAID:
1. Аппаратный, собираемый на RAID-контроллерах серверов (узлов) до загрузки ОС. Полученный объем и лицензиурется.
2. Софтовый, собираемый в Network RAID на базе тех томов, которые мы создали на первом уровне. Для конечного пользователя (администратора\менеджера виртуального кластера) именно этот объем будет «полезным», т.е. пригодным для использования.
Да, вы правы. Это просто короткая выжимка личных впечатлений, созданная с целью приглашения к началу диалога для всех заинтересовавшихся.
Это "энтузиазм новичка", нахватавшегося новых терминов и старающегося использовать их повсеместно :)
Да, только на территории РФ они недоступны, и не ясно когда появятся.
Да, только у xDrip+ есть огромное количество недостатков. Недоступность на iOS, отсутствие поддержки и внятной документации, нестабильная работа - в общем стандартный набор характеристик "народного" приложения.
А про поддержку разных типов датчиков шла речь не в контексте перехода между ними одним пользователем (что тоже происходит с определенной периодичностью), а с точки зрения обхвата максимально широкой аудитории.
Спасибо за уместные замечания, но эта статья задумывалась больше как информативная, нежели отчетная. Если кому-либо будет интересно продолжить работу в этом направлении, он может написать мне персонально, и я с радостью обменяюсь подробными наработками моей команды.
Как я писал в статье — на текущий момент там не полный перечень доступных опций.
Я рассматриваю данный продукт с точки зрения корпоративного рынка. И сравнивать его с бесплатными/открытыми решениями, неспособными предложить своим клиентам гарантию и соблюдение каких-либо SLA не вижу смысла.
Решения типа «собрать на коленке и накатить пиратскую версию чего-то там» никогда не будут поддерживаться и обслуживаться производителем. И ни один специалист никогда не внедрит такое к себе в продуктив. Поэтому не вижу смысла тратить время на сравнение их цен.
Да, только такой подход уместен для младших NAS-ов. Предлагать заказчику покупать два AFA для надёжности как минимум странно.
По оси абсцисс указано кол-во потоков, генерируемых приложениями. Поэтому и используются степени двойки.
Не очень понимаю, какое отношение обычный стоечный сервер имеет к AFA-массивам.
Подобное оборудование продается исключительно по проектной схеме, т.е. каждый раз согласовывается индивидуальная скидка. Поэтому сравнивать"уличный" ценник просто некорректно.
Подробнее: в общем виде используется ПО Application Aware Snapshot Manager, которое ставится на внешний хост и управляет процессом создания консистентных снэпшотов (вернее его координирует, т.к. создание снэпшотов доступно и из консоли самой VSA). Поддерживаются ОС Windows Server 2012, Windows Server 2012 R2, Windows Server 2012 R2 Core, Windows Server 2008, 32-bit и 64-bit versions, vSphere (5.0, 5.1, 5.5 и 6.0). Перед созданием аппаратного снэпшота производятся необходимые действия по остановке (заморозке, снэпшоту) приложения (файловой системы).
Чуть более подробно: можно определить два тира – 0 и 1. При подключении дискового пространства (датастора) в виртуальной машине VSA можно определить тип тира. По умолчанию все логические тома создаваемые внутри кластера используют оба тира. Все новые блоки всегда пишуться на тир 0 (пока там есть место), потом, по мере его заполнения, блоки начинают пистаться на тир 1. Все это время ведется т.н. heat map (карта горячих и холодных блоков на основе частоты обращений к них). Как только какие-то блоки становятся кандидатоми на миграцию, начинается миграция таких блоков. Для этого определяется равное кол-во холодных и горячих блоков и они перемещаются. Минимальный блок для миграции 256 КБ, общее кол-во таких блоков определяется динамически исходя из степени загрузки системы.
Не совсем согласен с вашим ответом.
Как таковых ограничений на размер тома нет. Есть лиценизонное ограние 50Тб на узел, в кластер собирается до 16 узлов, что на входе дает 800 Тб полезной емкости (до объединения в Network RAID).
Хочу добавить относительно StoreVirtual 3200 — продукт тоже крайне интерессный в плане переноса архитектуры SDS на аппаратную платформу. Коллеги обещали привезти его мне в демо до конца года. Как только получу на руки, то сразу напишу аналогичный обзор.
1. Аппаратный, собираемый на RAID-контроллерах серверов (узлов) до загрузки ОС. Полученный объем и лицензиурется.
2. Софтовый, собираемый в Network RAID на базе тех томов, которые мы создали на первом уровне. Для конечного пользователя (администратора\менеджера виртуального кластера) именно этот объем будет «полезным», т.е. пригодным для использования.