Smasher
+1

Что за глупости про SnapCenter?
MySQL используется по умолчанию для разворачивания на одном сервере. Поддерживается кластеризация серверов SnapCenter и использование MSSQL в HA. Плагины существуют под Windows, Linux/Unix, Oracle, MSSQL, VMware, SAP/SAP HANA. Плюс community-плагины под MongoDB, MySQL и DB2. Можно и самому собрать плагин для любого другого приложения.
Плагины живут на серверах с приложениями. Сам сервер SnapCenter используется в качестве репозитория плагинов и для централизованного управления.
Ну и никто еще не отменял SnapManager'ы.

Smasher
0

Вы жалуетесь на отсутствие данных, а почему не начать собирать данные краудсорсингом с это делает тот же Weather Underground с сетью персональных погодных станций? Все это дело возможно популязировать и построить большую сеть по России и/или СНГ.

Smasher
0

на фото не смотри — комментарии пиши. Там диск на 400GB. Мне и интересно зачем он там, если таких ёмкостей не продаётся.

Smasher
+2

Практика показала, что для работы опции space-allocation с VMware необязательно отправлять LUN в офлайн. Просто после включения space-allocation надо немного подождать.

Smasher
+1

Интересно зачем FlashCache для FAS9000 на 400GB, если минимально доступный 1TB?

Smasher
+1

SFP+ 1GbE RJ-45 можно купить :)

Smasher
0

А зачем вы компрессию называете архивированием? Это же разные понятия.


Как обстоят дела с производительностью после того как вы отказались от множества реплик?

Smasher
0

Кроме того, что в посте описал, еще добавили SnapMirror в AltaVault, FLI (Foreign LUN Import) для AFF.

Smasher
0

Компрессия на хранилище часто доступна бесплатно в отличии от компрессии в БД. Включение компрессии на хранилище и выключение на самом сервере БД позволяет тратить ресурсы CPU сервера БД на более нужные операции. Есть вендоры, у которых компрессия на хранилище не только не замедляет работу всего решения в целом, но и в некоторых случаях даёт прирост в производительности.

Smasher
+1

Принципиальных изменений не было. Расширили политики. А с 9.1 при совместном использовании FlashCache и FlashPool решается проблема прогрева кэша между перезагрузками или в случае failover.

Smasher
+1

Хранилище с полезной ёмкостью в 50TiB обходится нам, допустим, в 150 000$.
Без дедупликации мы сможем 50TiB своих данных. При коэффициенте дедупликации 10:1 мы сможем хранить 500TiB данных. И нам это по-прежнему будет стоить 150К$. При коэффициенте дедупликации 50:1 мы уже будем хранить 2500TiB данных
В первом случае мы тратим 3000$ за TiB, во втором 300$, а в третьем всего 60$.
Так к чему говорить про разницу в reduction ratio в 8%? Клиент считает свои деньги и в третьем случае получит возможность хранить в 5 раз больше данных.


Дедупликация, компрессия, уплотнение. HPE поддерживает что-то кроме дедупликации?
Кто из вендоров уплотнением называет дедупликацию+компрессию?
Есть данные для которых хорошо работает дедупликация — виртуальные среды, есть данные для которых лучше сработает компрессия — OLTP DB. И большинство извстных мне вендоров эти понятия разделяют.


Рис 6. Зависимость коэффициента дедупликации от количества виртуальных машин в пуле и размеров блока данных.
Немного бесполезный и вводящий в заблуждение график. Судя по тому, что заметный рост коэффициента дедупликации заметен при размере блока 16К и кратных ему, речь идёт про HP 3Par. При этом другие вендоры, использующие другую гранулярность при дедупликации могут получить другие результаты.
Smasher
+1

Придёт время расширять кластер и туда можно будет добавить уже новые железки.


А если серьёзно, то откуда такая огромная разница в NFS?

Тяжело что-то конкретное ответить. Возможно тестировали pNFS, а он сильно лучше параллелится :)
Как вариант, что старые системы тестировали без FlashCache, а новые в базе идут с NVMe FlashCache. Что даёт очень существенный прирост производительности для файловых нагрузок, при большом объеме работ с метаданными. Метаданные хорошо кэшируются.
Ну и не понятно соотношение чтения/записи. Графики производительности FC странные, так как в многих TR результаты получались выше.
Больше всего конечно порадовал прирост производительности при последовательных операциях.


Хотя стоит дождать публикации более серьёзных документов.

Smasher
+2
Ну как-то совсем скучно. Столько всего интересного же можно было рассказать про AFF и VDI. TR-4539, TR-4540, TR-4518, TR-4519 — содержат кучу интересной информации по конфигурации и производительности VDI решений на Horizon и Citrix XenDesktop.
Smasher
+1
Все же прекрасно находит.
Скриншот VMware HCL
image

Smasher
+1
Имеет. Все inline процессы происходят на контроллере до того как данные попадут на диски.
Smasher
+1
Inline data compaction «нагрузит» CPU на 1%-2%. Алгоритм адаптивный, если это как-то начинает влиять на скорость обслуживания данных, то ресурсы у compaction отбираются.
Вообще в ONTAP 9 опять поработали под капотом и производительность по сравнению с Data ONTAP 8.3.2 выросла даже с учётом включенных inline compression, compaction и deduplication.
Есть вот такое сравнение на коленке в симуляторе ONTAP.
А есть документ посерьезнее с тестами MS SQL на AFF8080.
Smasher
+2
Идеальный в своей бессмысленности маркетинговый пост на техническом сайте.
Smasher
+1
Блин. Перепутал со SnapCenter :)
Smasher
0
SnapCreator бесплатный, а вот плагины к нему нет.
Smasher
+1
Автор забыл еще упомянуть о поддержке дедупликации и компрессии.
Smasher
+1
AlwaysON, DAG, RAC и т.д. — это решения для обеспечения High Availability приложений. При этом они не спасают от порчи данных из-за человеческих ошибок и не только. Например, дропнутая таблица на одном сайте будет дропнутой и на другом. Так что не стоит путать резервное копирование и HA.
Smasher
0
А что с компрессией? В одной таблице указано, что сжатие недоступно на SSD, а по тексту написано, что сжатие работает на SSD.
Smasher
0
На самом деле завист от правильного сайзинга :)
Smasher
+2
Чем так плох 3Par, что у HPE 6 линеек СХД — MSA, StoreVirtual, StoreEasy, StoreAll, 3Par, XP? Никого не забыл? Со StoreAll не совсем уверен, как-то пропали эти системы с горизонта. Две из них еще и OEM продукты на самом деле. При этом ни одна из этих систем не была разработна внутри HPE. Поправьте меня, если я не прав.

Я не являюсь представителем NetApp и знать почему покупается SolidFire не могу.
Но как я вижу, SolidFire очень популярное решние среди провайдров услуг (service providers) и к тому же может работать на commodity hardware. Что не пересекается с текущими решениями NetApp. Так что я бы задавал вопрос иначе. Чем так хорош SolidFire, что его решил купить NetApp?
Smasher
+1
Я так понял, ответов по существу моего первого комментраия не будет?

Как уже написал товарищ ниже, доступных линеек all-flash две. Поэтому повторюсь, не стоит писать о том, в чем вы не разбираетесь. К тому, же используя блоги своих же конкурнетов.
Smasher
+1
Еще сюда можно добавить:
— гарантирует ли HPE доступность данных при выходе из строя более одного контроллера в системах с четырмя и более контроллерами
Smasher
+1
У NetApp уже 5 AFA линеек? Огласите весь список, пожалуйста. Может лучше не писать о тех вещах, в которых вы не разбираетесь?

Я говорю про линейку AFF. Она поддерживает до 24 контроллеров с файловым доступом и до 8 контроллеров при унифицированном доступе (Fc, FCoE, iSCSI, NFS, CIFS).
Smasher
+7
Я официально заявляю: HPE 3PAR StoreServ — это единственный настоящий корпоративный массив уровня Tier-1, полностью построенный на флеш-технологиях.

Это очень громкое утверждение, которые к тому же не является истиной.

Вы приводите 3 критерия соответсвуия массиву Tier-1:
  1. Производительность
  2. Отказоустойчивость
  3. Репликация данных


Массивы HPE 3Par не входят даже в десятку самых производительным по результатам теста SPC-1. Появятся результаты и это заявление будет иметь чуть больше ценности.

Критейрий отказоустойчивости в вашем случае — это наличе более двух контроллеров в AFA-массиве. Ну так EMC и NetApp предлагают своим клиентам многоконтроллерные AFA-массивы. В случае с NetApp в одной системе может быть до 24 контроллеров. Так что опять мимо с заявлением.

Ну и что касатеся репликации данных для AFA-систем. HPE не единственные. Как с этим обстоят дела у EMC не могу сказать, но в случае с NetApp возможна синхронная и асинхронная репликация между AFA-массивами, и репликация между AFA-системами и обычными дисковыми массивами.

При этом зачем-то сравниваете дедупликацию с функциональностью по интеграции с приложениями и надежностью SSD дисков.
Кстати, к вопросу о эффективности хранения данных. Наиболее востребовано использование AFA-систем для хранения баз данных. При этом дедупликация практически не дает особого выигрыша в полезном пространстве для OLTP, но при этом очень хорошо себя показывает компрессия. Что у HPE 3Par с компрессией? Кажется ее нет?

На первом изображении говорится о цене в 1.5$ за 1ГБ полезной емоксти. Это же с использованием дедуплкации? Так что у HPE с коэффициентом дедупликации-то? И что происходит с дедуплицированными данными при репликации?

Очень посредственный пост.
Smasher
0
Ну это очередной ребрендинг. В предыдущей версии создавалась федерация между Lync-инфраструктурой on-premises и Skype срерверами MS. Lync внутри себя использует SIP. Не думаю, что с переименованием что-то изменилось.
Smasher
0
Отличная схема. Но у вас там ошибка относительно MS Lync. Это продолжение MS Office Communicator, который вышел еще в 2007 году.
Smasher
–1
Кстати, друг подкинул ссылку на интересное обсуждение на тему на сколько Tox на самом деле децентрализован (на самом деле нет).
Smasher
+1
Ну удобство использования продукта обычно обратно пропорчионально его безопасности.
Smasher
+1
Странно, мне присылается код с подтверждением в Телеграм на устройства с активными сессиями. СМС можно послать по желанию.
скриншот
image
Smasher
0
802.11s только про Wi-Fi. В FireChat же mesh-сеть может работать и через Bluetooth.
Smasher
+2
Тут скорее проблема в другом. Для регистрации в Телеграм однозначно нужен номер телефона. И если ваш номер записан у кого-то в записной книжке, то он будет оповещен, когда вы зарегистрируетесь в Телеграме.
Smasher
0
Это пока утопичная идея. Если я правильно понимаю, то поддержка CJDNS должна осуществляться на уровне операционной системы. Если с *nix и BSD-like все понятно, то вот с мобильными ОС все хуже. Раз пока нет единого стандартна для организации mesh-сетей на уровне ОС, то проще все это реализовать на уровне своего приложения.
Smasher
+3
Комнаты так и остались. Общаться можно через интернет, но при его отсутствии формируются сеть пользователями поблизости и для передачи сообщений используется Bluetooth, Wi-Fi. Я им активно не пользовался, так что не знаю на сколько там все удобно реализовано. Стоит на черный день :)
Smasher
+3
Почему не упоминается FireChat?
Smasher
0
Все понятно с синтетическими тестами, но неплохо тестировать хотя бы с 8к блоком. Не знаю приложений, которые в реальной жизни работают с 4к блоком.
Что будет с производительностью и задержками, когда на пути данных появится SVC?