В целом неплохой краткий обзор для "начинающих" :), несмотря на предупреждения TL;DR.
Хотя интересно было бы узнать мнение человека действительно первый раз читающего про хранение данных.
Вот ровно по этому проще привыкать к тому, что стандартно почти везде по умолчанию. А все эти украшательства просто баловство от нечем заняться. Разве что дома на линуксе сидишь или имеешь PET проект, с которым постоянно ковыряешься. Таскать это по всем поддерживаемым серверам или тем серверам куда тебе пришлось по каким то причинам залогиниться, все равно не будешь.
Логика к сожалению не моя, а общепринятая в отрасли. Продукты VMware — это лишь как наглядный пример. Можете почитать англоязычные ресурсы и описание определений Bare Metal Hypervisor и Hosted Hypervisor.
Но с другой стороны вам не кто не мешает изобрести и использовать собственные логические построения :) и жить с ними.
По факту Bare Metal Hypervisor это и есть OS :). Если хотите пойти в частности, то обычно это обрезанная до функционала работы с виртуальным машинами OS. Большинство "лишних" вещей дающих дополнительный оверхед по управлению и производительности вырезаны, в отличии от полноценной OS и установленного в нее Hosted Hypervisor.
Если это не шутка :), то на пальцах:
Hosted Hypervisor устанавливается в операционную систему. Н-р: VMware Workstation установленный в OS Windows. И уже в нем запускаются виртуальные машины.
Bare Metal Hypervisor устанавливается на "голое железо". Н-р: VMware ESXi установленный на сервер.
В этом случае вы можете купить одну единственную систему PowerStore которая закроет все задачи, т.к. само приложение и сервер резервного копирования можно развернуть в рамках узла PowerStore без необходимости в дополнительной инфраструктуре.
"Отличный пример", т.е. в случае чего мы сразу теряем и первичный данные и их бэкапы? :).
Про CS вы это зря. Давно напридумывали скинов и продают только в путь. Еще и рынок продажи/покупки между пользователями, где с каждой продажи Valve себе процент берет :). И все младое поколение млеет от этих картинок не влияющих не игровой баланс.
Сюда например загляните :) https://steamcommunity.com/market/search?q=#p6_popular_desc
Это не только у HP, но так делать плохая идея. Диск выводиться из конфигурации по мере накопления ошибок ввода/вывода (при превышении заданного порога). После вытащил/вставил, если СХД оперирует слотами (номерами слотов), а не дисками (серийниками дисков), получаем ситуацию у нас "новый" диск и счетчик ошибок обнулился. Вроде бы "отлично", но дальше идет накопление ошибок на диске по новой. А так как диск проблемный, то накопление ошибок будет только ускоряться. И вот в следующий раз когда диск умрет или система его отщелкнет по превышению порога ошибок у вас может еще один диск подойти к тому же состоянию. И получаете вы duble (Raid5) или triple (Raid6) paity error и машете ручкой потерянным по своей глупости данным. Хорошо если не сильно старые бэкапы есть и место куда восстановиться.
Так что если система гарантийная, то такие диски обязательно нужно менять а не ресетить. Если не гарантийная, то искать пути замены проблемных дисков все равно.
— достаточной мобильности рабочих мест при их перемещении ( любят разного рода кабинетные менеджеры двигать рабочие места )
Не соглашусь с этим плюсом, беспроводную передачу электропитания еще не придумали. Так что все равно электро розетки ставить. Почему бы и слаботочку не протянуть в таком случае? Но если будут в будущем много двигать, то и розеток и тех и тех много нужно будет для обеспечения "мобильности" рабочих мест в пределах офиса.
Да я в общем-то согласен :). Потому и написал, что тут вопрос цены. Ну и не плохо когда вся цепочка продаж и сам заказчик понимает в чем разница между сырой емкостью и полезной.
C 2 часовым таймаутом вопрос с логикой, которой пользуется система при возвращении потерянной ноды обратно в онлайн менее чем за время таймаута. Если записанные на нее "третьи" копии данных просто продолжат использоваться, то возможно таймаут как раз предусмотрен для того, что бы решить проблему с нодой, если она не требует много времени, и вернуть ее в работу. При этом избежать ребилда всего, что на потерянную ноду было записано. Все же для продуктивного кластера ребилд не лучшее времяпрепровождение.
А с RF3 все равно остается вопрос стоимости в переводе на реальную полезную емкость такого решения. Насколько помню, у HyperFlex 8% дисковой емкости блокируется под хранение метаданных (а кто может обойтись без них?). В таком случае из условных 100TB сырой емкости нам остается 92TB. Рекомендованный RF3 оставляет нам около 30.7 TB. А далее рекомендованная Cisco "cluster storage utilisation" не более 70% от этих оставшихся 30.7TB. В итоге на выходе из условных 100TB "сырых" получаем примерно 21,5TB под полезные данные + снэпшоты. Понятно, что в теории использование дедупа и сжатия может компенсировать нам часть этих потерь. Но есть сомнения, что на реальных первичных данных коэффициент будет хотя бы 3:1.
В целом неплохой краткий обзор для "начинающих" :), несмотря на предупреждения TL;DR.
Хотя интересно было бы узнать мнение человека действительно первый раз читающего про хранение данных.
Вот ровно по этому проще привыкать к тому, что стандартно почти везде по умолчанию. А все эти украшательства просто баловство от нечем заняться. Разве что дома на линуксе сидишь или имеешь PET проект, с которым постоянно ковыряешься. Таскать это по всем поддерживаемым серверам или тем серверам куда тебе пришлось по каким то причинам залогиниться, все равно не будешь.
Логика к сожалению не моя, а общепринятая в отрасли. Продукты VMware — это лишь как наглядный пример. Можете почитать англоязычные ресурсы и описание определений Bare Metal Hypervisor и Hosted Hypervisor.
Но с другой стороны вам не кто не мешает изобрести и использовать собственные логические построения :) и жить с ними.
По факту Bare Metal Hypervisor это и есть OS :). Если хотите пойти в частности, то обычно это обрезанная до функционала работы с виртуальным машинами OS. Большинство "лишних" вещей дающих дополнительный оверхед по управлению и производительности вырезаны, в отличии от полноценной OS и установленного в нее Hosted Hypervisor.
Если это не шутка :), то на пальцах:
Hosted Hypervisor устанавливается в операционную систему. Н-р: VMware Workstation установленный в OS Windows. И уже в нем запускаются виртуальные машины.
Bare Metal Hypervisor устанавливается на "голое железо". Н-р: VMware ESXi установленный на сервер.
Вот по мне так тоже памятку лучше было статьей оформить. А не ссылку на pdf в короткой статье давать :).
Тут вроде как описана возможность и на инстаграм в том числе стримить, хоть и не совсем нативно https://support.restream.io/en/articles/841983-how-to-go-live-on-instagram.
Утверждение выше говорит об обратном. Ну и потеря самого бэкап сервера, внезапно, усложняет восстановление из бэкапа, если уж на то пошло.
А не пробовали смотреть в сторону чего то такого https://support.restream.io/en/articles/872029-list-of-all-restream-supported-services?
PowerMAX же :).
"Отличный пример", т.е. в случае чего мы сразу теряем и первичный данные и их бэкапы? :).
Они влияют только на неокрепшие умы :) и на жадность Valve, которая больше заморачивается со скинами, чем с античитом и читерами.
Про CS вы это зря. Давно напридумывали скинов и продают только в путь. Еще и рынок продажи/покупки между пользователями, где с каждой продажи Valve себе процент берет :). И все младое поколение млеет от этих картинок не влияющих не игровой баланс.
Сюда например загляните :) https://steamcommunity.com/market/search?q=#p6_popular_desc
Ясно. Просто ваш комментарий выглядел как будто ресет диска это некая "суперфича". Меня это задело за больную мозоль. :)
Простите если что :).
Это не только у HP, но так делать плохая идея. Диск выводиться из конфигурации по мере накопления ошибок ввода/вывода (при превышении заданного порога). После вытащил/вставил, если СХД оперирует слотами (номерами слотов), а не дисками (серийниками дисков), получаем ситуацию у нас "новый" диск и счетчик ошибок обнулился. Вроде бы "отлично", но дальше идет накопление ошибок на диске по новой. А так как диск проблемный, то накопление ошибок будет только ускоряться. И вот в следующий раз когда диск умрет или система его отщелкнет по превышению порога ошибок у вас может еще один диск подойти к тому же состоянию. И получаете вы duble (Raid5) или triple (Raid6) paity error и машете ручкой потерянным по своей глупости данным. Хорошо если не сильно старые бэкапы есть и место куда восстановиться.
Так что если система гарантийная, то такие диски обязательно нужно менять а не ресетить. Если не гарантийная, то искать пути замены проблемных дисков все равно.
если мерять количество дисков на 1U, то есть и такое:
Не соглашусь с этим плюсом, беспроводную передачу электропитания еще не придумали. Так что все равно электро розетки ставить. Почему бы и слаботочку не протянуть в таком случае? Но если будут в будущем много двигать, то и розеток и тех и тех много нужно будет для обеспечения "мобильности" рабочих мест в пределах офиса.
На слайдах масштабирование по контроллерам 2-16 и 2-32, а в тексте речь только про 8. Где подвох?
Да я в общем-то согласен :). Потому и написал, что тут вопрос цены. Ну и не плохо когда вся цепочка продаж и сам заказчик понимает в чем разница между сырой емкостью и полезной.
C 2 часовым таймаутом вопрос с логикой, которой пользуется система при возвращении потерянной ноды обратно в онлайн менее чем за время таймаута. Если записанные на нее "третьи" копии данных просто продолжат использоваться, то возможно таймаут как раз предусмотрен для того, что бы решить проблему с нодой, если она не требует много времени, и вернуть ее в работу. При этом избежать ребилда всего, что на потерянную ноду было записано. Все же для продуктивного кластера ребилд не лучшее времяпрепровождение.
А с RF3 все равно остается вопрос стоимости в переводе на реальную полезную емкость такого решения. Насколько помню, у HyperFlex 8% дисковой емкости блокируется под хранение метаданных (а кто может обойтись без них?). В таком случае из условных 100TB сырой емкости нам остается 92TB. Рекомендованный RF3 оставляет нам около 30.7 TB. А далее рекомендованная Cisco "cluster storage utilisation" не более 70% от этих оставшихся 30.7TB. В итоге на выходе из условных 100TB "сырых" получаем примерно 21,5TB под полезные данные + снэпшоты. Понятно, что в теории использование дедупа и сжатия может компенсировать нам часть этих потерь. Но есть сомнения, что на реальных первичных данных коэффициент будет хотя бы 3:1.