Pull to refresh
28
0

Архитектор решений

Send message
AlwaysON, DAG, RAC и т.д. — это решения для обеспечения High Availability приложений. При этом они не спасают от порчи данных из-за человеческих ошибок и не только. Например, дропнутая таблица на одном сайте будет дропнутой и на другом. Так что не стоит путать резервное копирование и HA.
А что с компрессией? В одной таблице указано, что сжатие недоступно на SSD, а по тексту написано, что сжатие работает на SSD.
Чем так плох 3Par, что у HPE 6 линеек СХД — MSA, StoreVirtual, StoreEasy, StoreAll, 3Par, XP? Никого не забыл? Со StoreAll не совсем уверен, как-то пропали эти системы с горизонта. Две из них еще и OEM продукты на самом деле. При этом ни одна из этих систем не была разработна внутри HPE. Поправьте меня, если я не прав.

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

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

Я говорю про линейку AFF. Она поддерживает до 24 контроллеров с файловым доступом и до 8 контроллеров при унифицированном доступе (Fc, FCoE, iSCSI, NFS, CIFS).
Я официально заявляю: 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 с коэффициентом дедупликации-то? И что происходит с дедуплицированными данными при репликации?

Очень посредственный пост.
Ну это очередной ребрендинг. В предыдущей версии создавалась федерация между Lync-инфраструктурой on-premises и Skype срерверами MS. Lync внутри себя использует SIP. Не думаю, что с переименованием что-то изменилось.
Отличная схема. Но у вас там ошибка относительно MS Lync. Это продолжение MS Office Communicator, который вышел еще в 2007 году.
Кстати, друг подкинул ссылку на интересное обсуждение на тему на сколько Tox на самом деле децентрализован (на самом деле нет).
Ну удобство использования продукта обычно обратно пропорчионально его безопасности.
Странно, мне присылается код с подтверждением в Телеграм на устройства с активными сессиями. СМС можно послать по желанию.
скриншот
image
802.11s только про Wi-Fi. В FireChat же mesh-сеть может работать и через Bluetooth.
Тут скорее проблема в другом. Для регистрации в Телеграм однозначно нужен номер телефона. И если ваш номер записан у кого-то в записной книжке, то он будет оповещен, когда вы зарегистрируетесь в Телеграме.
Это пока утопичная идея. Если я правильно понимаю, то поддержка CJDNS должна осуществляться на уровне операционной системы. Если с *nix и BSD-like все понятно, то вот с мобильными ОС все хуже. Раз пока нет единого стандартна для организации mesh-сетей на уровне ОС, то проще все это реализовать на уровне своего приложения.
Комнаты так и остались. Общаться можно через интернет, но при его отсутствии формируются сеть пользователями поблизости и для передачи сообщений используется Bluetooth, Wi-Fi. Я им активно не пользовался, так что не знаю на сколько там все удобно реализовано. Стоит на черный день :)
Почему не упоминается FireChat?
Все понятно с синтетическими тестами, но неплохо тестировать хотя бы с 8к блоком. Не знаю приложений, которые в реальной жизни работают с 4к блоком.
Что будет с производительностью и задержками, когда на пути данных появится SVC?
Странно, что не упоминается анонс от Samsung о доступности в следующем году SSD емкостью в 16ТБ. То есть SSD уже превысят по объему HDD, которые пока достигли емкости в 10ТБ и испытывают некоторые трудности с дальнейшим ростом емкости. А самое главное, что никаких вариантов увеличения производительности HDD на горизонте не видно. При этом 16ТБ SSD от Samsung это только начальный этап и дальше емкость будет только расти. Так что мне кажется, что разница в цене между SSD и SATA HDD будет меньше 5-10 раз уже через год. Уже сейчас стоимость TLC SSD на уровне enterprise SAS дисков. В итоге в ближайшее время придем к тому, что в ЦОДах останутся только SSD и SATA диски для архивного хранения.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity