Storage: две непримиримые школы

[Dmitry67]

У нас на работе образовались две непримиримые школы. Первая - классическая, дорогие external storages. Аргументы второй школы в утрированном виде выглядят так: "моя локальная SSD за $100 купленная в соседнем магазине порвет ваш супер пупер дорогой netApp как тузик грелку". Я вижу разумное в походах обеих школ (понятно, наше IT относится к "классической"). Тем не менее я попытался заронить сомнение у нашего NetApp guy. Ну в духе фильма "Inception", вложить ему в голову своеобразный волчок сомнения. Состоялся интереснейший чат, содержание которого я перескажу по русски. Речь пошла про physical box, для которого и собирали мощный storage (там ожидается очень большая нагрузка на SQL)

Я: (как бы наивно так) А зачем на на Physical Box иметь net storage, в частности NetApp?
Он: High Availability
Я: Но ведь не только storage, но и сама машина должна быть HA. А значит нужен кластер
Он: Ну да
Я: А значит Enterprise Edition of SQL server
Он: Ну да
Я: А значит мы имеем AlwaysOn groups бесплатно. Мы можем поставить local and cheap SSD storages, и даже сделать например две машины для HA, а третью в другом datacenter, для DR
Он: Ну, не забывай что NetApp - это еще и scalability
Я: Oh c'mon, ну какое scalability? У нас все выпрашивают крохи по 10-20Gb, тогда как можно за те же $100 купить гиг (*)
Он: Ну так Production storage на порядок дороже
Я: Естественно. Потому что у него есть HA, replication, storage level snapshot backup, которые в данном случае совершенно не нужны
Он: Хм... (реально задумался). Но я не представляю, чтобы ктото в серьезной компании, допустим банке, доверил бы данные ненадежному storage, которым являются local SSDs.
Я: Ну так в NetApp каждый диск по отдельности тоже ненадежен. Важна комплексная надежность системы, и в данном случае надо сравнивать с комплексом AlwaysOn группы
Он: Ну и почему никто не использует это решение?
Я: Потому что оно еще слишком свежее, чтобы пойти в PROD. В SQL 2012 у AlwaysOn был принципиальный design flaw, а SQL 2014 еще только идет в production.
Он: Тем не менее это решение difficult to manage. А если таких серверов много?
Я: Согласен. Разумеется, это не для наших сотен VMs, а для пары экстримальных серверов

Что скажете?
Какие аргументы подкинете?

(*) Я вижу здесь подобие спора с zVlad-МФ. Например, NetApp так здорово делает deduplication, экономя такое дорогое место на диске... Которое при подходе второй школы экономить просто не надо. Ну итд.

[zVlad]

У нас на работе образовались две непримиримые школы. Первая - классическая, дорогие external storages. Аргументы второй школы в утрированном виде выглядят так: "моя локальная SSD за $100 купленная в соседнем магазине порвет ваш супер пупер дорогой netApp как тузик грелку".
....
Что скажете?
Какие аргументы подкинете?

(*) Я вижу здесь подобие спора с zVlad-МФ. Например, NetApp так здорово делает deduplication, экономя такое дорогое место на диске... Которое при подходе второй школы экономить просто не надо. Ну итд.

Здесь, по моему, не две школы, а элементарное не понимание реальных требовании больших ИТ. Не понимание того что поделушки для дома и семьи и оргомные производства где когда система недоступна никто не захочет слушать что мол мы сэкономили несколько сотен тысяч долларов (или даже миллионов) на инфраструктуре и вот теперь нам надо долго восстанавливать наши данные и системы. А причина может быть банальной - затопило датацентр из прорвавшейся трубы (у нас не так давно именно так и было. Вода лилась на МФ и на дисковую подсистему. Зачинался по этому поводу целый проект с многими сотнями тысяч долларов только на зарплату).

Ваш оппонент инстиктивно понимает что то что Вы предлагаете не годится, он верит в доказанность надежности и других качеств того решения к которму Ваша фирма пришла за годы борьбы с проблемами. А Вы, Дима, видите только цену гигабайта. Никто уже в серьезных организациях ИТ не смотрит на это. Все понимают что надежная ИТ большого бизнеса не может строиться на компонетах для домашней поделушки.

Кстати по поводу дедупликации я инстинктивно против. При этом создается большая зависимость от софта и управляющих данныхх потеря которых или баг в которых могут привести огромные обемы смысловой информации в бессмысленный набор байтов. Т.е. физически данные будут в порядке, но превратить их в логически нормальную форму будет невозможно.

Еще раз повторю - тут нет никаких двух школ. Есть нормалые специалисты и приемы решения вопросов ИТ и есть авантюристы вроде Вас, Дима, предлагающие сэкономить на туалетной бумаге.

[Dmitry67]

А причина может быть банальной - затопило датацентр из прорвавшейся трубы (у нас не так давно именно так и было. Вода лилась на МФ и на дисковую подсистему.

Опять вы zVlad начали с апломбом свои оскорбления, даже не прочитав что я написал
Специально для вас повторю и выделю:

Я: А значит мы имеем AlwaysOn groups бесплатно. Мы можем поставить local and cheap SSD storages, и даже сделать например две машины для HA, а третью в другом datacenter, для DR

Кстати по поводу дедупликации я инстинктивно против. При этом создается большая зависимость от софта и управляющих данныхх потеря которых или баг в которых могут привести огромные обемы смысловой информации в бессмысленный набор байтов. Т.е. физически данные будут в порядке, но превратить их в логически нормальную форму будет невозможно.

Какого же софта?
Для пользовательского софта дедупликация прозрачна
От firmware storage (это не называется софтом) зависимость есть не зависимо от того, есть дедупликация или нет
Тот же NetApp хранит данные в своем проприетарном формате
Так что опять у вас элементарное непонимание прописных истин

[zVlad]

Кстати по поводу дедупликации я инстинктивно против. При этом создается большая зависимость от софта и управляющих данныхх потеря которых или баг в которых могут привести огромные обемы смысловой информации в бессмысленный набор байтов. Т.е. физически данные будут в порядке, но превратить их в логически нормальную форму будет невозможно.

Какого же софта?
Для пользовательского софта дедупликация прозрачна
От firmware storage (это не называется софтом) зависимость есть не зависимо от того, есть дедупликация или нет
Тот же NetApp хранит данные в своем проприетарном формате
Так что опять у вас элементарное непонимание прописных истин

Не надо горячиться и забегать вперед. То, что это прозрачно для пользовательского софта об этом можно было бы не говорить. А вот зависимость от проприетари форматов я бы избегал чтобы не остаться с дисками заполненными бессмысленными, без проприетари софта, байтами.
И вообще, не кажется ли Вам непоследовательным с одной стороны обещания завалить дешевыми ресурсами какие угодно запросы и тут же пытаться экономить на дедубликации . Кстати еще уместно вспомнить о денормализация за которую тут и Вы по моему заступились как то. А ведь это диаметрально противоположные, взаимоисключающие тенденции.

[iDesperado]

не уверен, что мне нравиться подход, но можно привести как аргумент биг дата решения, где так же ставка на локальные диски, а redundancy and availability софт обеспечивает. правда я бы первопроходцем с AlwaysOn стать не рискнул бы.

[DropAndDrag]

ничего не понятно - данных нету.
Вот пара крайних примеров:
если чувак разрабатывает программу непривязанную к конкретике, то может легко сидеть на своем компе и будет ему SSD за счастье.
если чувак разрабатывает программу для определенных объемов данных и storage в итоге будет нужен соотвестующий, то на месте чувака, я бы вам объяснил, что во что обходится зоопарк

[Palych]

Я в тонкостях ввода/выводя не импотентен, но по-крестьянски рассуждаю так:
Если ввод-вывод асинхронный - система говорит: "мне нужен такой-то блок", и в ожидании ответа продолжает заниматься своими делами.
Если диск свой и один - все запросы выстраиваются в очередь. К тому же драйверу возможно придётся занимать тот же процессор какими-то манипуляциями с устройством (USB например).
Если дисками управляет отдельный сервер - он может разбросать задачи на разные процессоры и диски. Но на переброску данных потребуется время.
То есть - тесты "hello world" будут летать быстрее на локальном диске из-за минимальных задержек, а NetApp будет меньше проседать под боевой нагрузкой.
Но как Dmitry67 справедливо подмечает - скорость обработки одиночных запросов вполне может заменить параллелизм. Если система успевает отрабатывать запросы - какая разница как это достигается?

[iDesperado]

Если ввод-вывод асинхронный - система говорит: "мне нужен такой-то блок", и в ожидании ответа продолжает заниматься своими делами.
Если диск свой и один - все запросы выстраиваются в очередь. К тому же драйверу возможно придётся занимать тот же процессор какими-то манипуляциями с устройством (USB например).

локальные диски не отменяют raid. операциями ио занимается контроллер используя механизм DMA, процессор в ио по сути не участвует. учитывая, что нагрузка планируется серьезная, Дмитрию без raid и контроллера никак не обойтись.

[Dmitry67]

Ну, striping сиквел может делать и сам. Сколько максимум sata ssd дисков можно запихнуть без извращений?

[iDesperado]

Ну, striping сиквел может делать и сам. Сколько максимум sata ssd дисков можно запихнуть без извращений?

sata ssd думаю не проканает. сата думаны на десктопы. на сколько я слышал для серверной нагрузки, где много перезаписи планируется под ssd более дорогие мозги нужны. поэтому для серверов чуток другие ssd диски делают.
P.S. а что за striping сиквела ?

[Dmitry67]

Ну так можно создать под любую файлгруппу много файлов, и положить на разные диски. При записи в таблицу расти будут все файлы одновременно, и таблица окажется размазана про всем дискам. Соответсвенно, при full table scan например сиквел будет читать в параллель со всех дисков

[iDesperado]

Ну так можно создать под любую файлгруппу много файлов, и положить на разные диски. При записи в таблицу расти будут все файлы одновременно, и таблица окажется размазана про всем дискам. Соответсвенно, при full table scan например сиквел будет читать в параллель со всех дисков

это не то ... а если карта ляжет не удачно ? а если олтп запросы восновном долбят данные текущего дня упавшие в один файл ? мне кажется субд без raid совсем никак.

[Dmitry67]

Так и данные последнего дня тоже размажутся. Он старается равномерно мазать. Конечно иметь штук 10 дисков без резервирования имеет небольшую наработку на отказ

[iDesperado]

Так и данные последнего дня тоже размажутся. Он старается равномерно мазать. Конечно имеет штук 10 дисков без резервирования имеет небольшую наработку на отказ

the SQL Server Database Engine writes an amount proportional to the free space in the file to each file within the filegroup, instead of writing all the data to the first file until full. It then writes to the next file. For example, if file f1 has 100 MB free and file f2 has 200 MB free, one extent is allocated from file f1, two extents from file f2, and so on. In this way, both files become full at about the same time, and simple striping is achieved.

если добавил/убрал диск, что тогда ? как этим управлять ? имхо админы вас четвертуют. еще важный момент с кешем контроллера. на сколько я видел без кеша контроллера скорость записи на порядок медленнее.

[Dmitry67]

Вы можете перенести ыайл на другой диск, но базу надо будет временно перевести в offline. Если online то есть операция освобождения файла путем переноса его данных в другие. Я сам админ )

[krids]

Я: Согласен. Разумеется, это не для наших сотен VMs, а для пары экстримальных серверов

Что скажете?
Какие аргументы подкинете?

case by case, каждой задаче - свой инструмент. Выбор storage layer для нагруженных и критичных БД обычно определяется требованиями к RPO/RTO, performance SLA, бюджетом и т.д.
Внешние СХД штука хорошая, но дорогая (особенно уровня midrange и выше). Дополнительные диски/полки для расшивки проблем производительности (особенно SSD) вылетают в "копеечку". Если бизнес готов без вопросов проплачивать счета от вендора, то почему бы и нет. Другое дело когда бюджет ограничен. Тут локальный DAS (с соответствующими контроллерами и дисками) выходит в разы дешевле.

Основной вопрос при выборе DAS vs SAN/NAS - кто будет отвечать за доступность БД.

Как бы не был хорош и надежен внешний стородж это все равно SPOF - так что для критичных продакшенов все равно брать два и делать между ними репликацию (с которой тоже не все бывает гладко, про особенности тех же неттапов можно user case посмотреть). Так что тут "конечный результат" и гарантия того что копия БД на резервной CХД на 100% валидна и доступна от DBA уже мало зависит.
В случае локального стороджа наоборот все в руках DBA (как и полная ответственность за корректную работу DataGuard, AlwaysOn, HADR, etc).

[zVlad]

...
локальные диски не отменяют raid. операциями ио занимается контроллер используя механизм DMA, процессор в ио по сути не участвует. учитывая, что нагрузка планируется серьезная, Дмитрию без raid и контроллера никак не обойтись.

Я ждал зацепочку за этот вопрос, вот он. Давайте разберемся насколько контролер разгружает процессор от ввода-вывода? Кто-нибудь может акуратно и кратро пояснить что в вводе-выводе делает процессор, а что контролер, что дравер (сиречь процессор), а что железо (сиречь контролер и само устройство).

Понятное дело что все это затевею чтобы показать силу МФ в вводе-выводе. Показывал строго говоря уже много раз, но слушатели у меня здесь собрались главным образом не злопамятные. Поэтому если кому интересно давайте повторим тему.

[Dmitry67]

Вопрос интересный. Потому что для механики классических дисков было все равно, а вот при скоростях, на которых работают SSD становится важным буквально все. Именно поэтому я затеял этот разговор. На работе конечно проведу эксперимент

[DropAndDrag]

...
локальные диски не отменяют raid. операциями ио занимается контроллер используя механизм DMA, процессор в ио по сути не участвует. учитывая, что нагрузка планируется серьезная, Дмитрию без raid и контроллера никак не обойтись.

Я ждал зацепочку за этот вопрос, вот он. Давайте разберемся насколько контролер разгружает процессор от ввода-вывода? Кто-нибудь может акуратно и кратро пояснить что в вводе-выводе делает процессор, а что контролер, что дравер (сиречь процессор), а что железо (сиречь контролер и само устройство).

Понятное дело что все это затевею чтобы показать силу МФ в вводе-выводе. Показывал строго говоря уже много раз, но слушатели у меня здесь собрались главным образом не злопамятные. Поэтому если кому интересно давайте повторим тему.

давно это было ... в случае когда io контроллер передат данные в память:
1. в памяти есть программа окончания DMA операции (стартовый адрес программы - это вектор прерывания)
2. процессор подвязывает какое-то прерывание к этой программе, выделяет кусок памяти и дает команду io устройству с передачей адресов памяти, номер и вектор прерывания.
2. io устройство каким-то образом собирает данные (не обязательно все за раз! также есть максимальный объем данных за один раз) во внутреннем буфере. в это время процессор работает как хочет
3. io устройство захватывает шину и организует DMA передачу. так делает несколько раз пока не передаст все данные. процессор не работает. скорость передачи по DMA быстрее раза в 3-4, чем операции единичного чтение (в основном за счте только одной операции записи вместо записи+чтения)
4. io устройство выставляет прерывание и вектор прерывания на шине адреса. процессор обрабытывает прерывание, т.е. выполняет программу окончания DMA операции

бывают DMA операции и поприкольнее. например, для длительного получения данных io устройство заполняет буфер и начинает писать сначала. прерывание шлется не по окончанию, а когда буфер заполнен новыми данными на 30-50-70%

но все эти знания в общем-то мало что дают при современных компьютерах, а тем более при больших монстрах. У современных компов куча промежуточных интерфейсов, да еще и с буферами. чем ближе интерфейс к процессору, тем скорость его выше. да и подсистема памяти может быть организована похитрее и иметь несколько каналов доступа, так что шина процессора может продолжать работать.
а если говорить о вопросе TC, то нужно еще меньше знать )))
я не знаю как быстро выполняются единичные запросы в базу данных (тут тоже вариаций полно, даже если учесть такой момент что часть базы данных может быть загружена в память), но при обсуждении времени доступа к локальному SSD и центральному файл серверу, мне кажется нет большого смысла обсуждать базу данных, а имеет смысла обсуждать передачу различных файлов и их комбинаций.
при SSD используется цепочка - шина - SATA контроллер - SSD
при внешнем файл-сервере используется цепочка - шина - network controller (который тоже имеет DMA, да еще может быть и умным, например делать одну DMA на несколько сетевых транзакций за счет своего буфера) - 1 GB сеть (10 GB стоит до хрена) - внешний файл-сервер

при запросе файла на 1-10-100-1000 байт (до блока файловой системы) SSD и даже обычный диск сделает внешний супер-пупер файл-сервер (головка диска должна выставится на нужную дорожку да еще время передачи через сеть)
при больших файлах SSD скорее всего не будет работать хуже. я делал перекидывал 1 GB файл и можно прикинуть сколько времени занимает в операции действия обычного диска, SSD, и сети+внешнего сервера.

так что со скоростями локальный SSD и даже без RAID выглядит хорошо - дешево и сердито! но надо смотреть дальше
например, если база данных будет расбросана по куче SSD. в какой-то момент 5-10-100 клиентам понадобятся данные с конкретного места. могу сказать, что это будет медленно! а в случае обычных дисков и больших файлов этот комп повиснет с 3-5 клиентами.
или другой пример, центральный файл-сервер с базой данной и кусок базы данных подкаченный на локальный диск. бля, мы круты и танки наши быстры ... хрен вам! какой-то козел-коллега что-то сменил и именно в закаченном куске и все система начинает синхронизоваться. а это уже не хухры-мухры - это похлеще DMA, это надо как бы сделать операцию чтение-запись за один такт на куче разных компьютеров
в итоге - за все надо платить! самое простое - это один комп и все пошли на XYZ. как только появляется второй, то это не еще один, а это multiple и возникает куча моментов. Лучший подход - "каждому chicken свой cage" говорил мой знакомый негр, но реально это плагиат с Гай Юлия Цезаря - разделяй и властвуй!
Все мы добрались почти до времен возникновения Земли. Увы, мало что поменялось в базовых подходах пойду я лучше поплаваю

[Poryadok]

У нас на работе была проблема - когда программа слишком перегружала диск, другая программа ждала и вываливалась по таймауту (там речь шла о секундах или долях секунды). Пока смежники переделывали софт на более грамотную буфферизацию, решили по-быстрому перенести запись второго софта на другой диск. И это, естественно, полностью решило проблему. Но был ещё третий софт (бэкап), который по ночам создавал туже проблему, а система должна работать 24/7
Фигня, добавили третий хдд.
И - о чудо - проблема НЕ исчезла
Оказалось, что в хоть в системе и 3 хдд, но контроллеров только 2, и когда на один из хдд, подключеномому к контроллеру что-то пишется, второй хдд на том же контоллере ждёт.
На всякий случай - речь идёт о современной дорогой xeon-системе.
Вобщем, пришлось таки переписать софт чтобы он не падал если хдд быстро не отвечает.
Я хочу сказать, узкое место не всегда там, где ожидаешь - кто бы мог подумать, что все упрется в контроллер хдд!

[iDesperado]

Я ждал зацепочку за этот вопрос, вот он. Давайте разберемся насколько контролер разгружает процессор от ввода-вывода? Кто-нибудь может акуратно и кратро пояснить что в вводе-выводе делает процессор, а что контролер, что дравер (сиречь процессор), а что железо (сиречь контролер и само устройство).

несколько лет назад я пытался найти, но целостной картинки не нашел. по разным источникам у меня сложилась такая картинка:
мсскл дергает ReadFileScatter из виндовс API, API дерагет драйвер который передает на SCSI контроллер SCSI команды, после чего процессор занимается своими делами. нормальный контроллер очередь SCSI команд может оптимизировать. например переставить команды местами, если понимает, что нужные блоки рядышком. после того как контроллер блоки достал, он через механизм DMA (direct memory access) в обход процессора складывает байты в центральную память. когда байты в памяти, через прерывание отдает управление процессору. контроллеров обычно несколько и они друг друга могут заменять.

[Mark]

Дмитрий а может AlwaysOn делать snap clone? т.е. предположим у вас 10 Tb данных в production и вам надо сделать клон PROD to QA для того чтоб протестить какую-то проблему. При вашем подходе вам понадобится 10Tb на PROD и еще 10Tb на QA (а ведь может быть еще DEV/TEST/UAT) и что везде будете совать локальные SSD и потом долго и нудно сливать 10Tb по сетке?
A netapp сделает snapshot за секунду и и при этом snapshot = delta между PROD и QA (т.е. на QA в реальности займет мегов 100 (не TB а Mb).

[zVlad]

Я ждал зацепочку за этот вопрос, вот он. Давайте разберемся насколько контролер разгружает процессор от ввода-вывода? Кто-нибудь может акуратно и кратро пояснить что в вводе-выводе делает процессор, а что контролер, что дравер (сиречь процессор), а что железо (сиречь контролер и само устройство).

несколько лет назад я пытался найти, но целостной картинки не нашел. по разным источникам у меня сложилась такая картинка:
мсскл дергает ReadFileScatter из виндовс API, API дерагет драйвер который передает на SCSI контроллер SCSI команды, после чего процессор занимается своими делами. нормальный контроллер очередь SCSI команд может оптимизировать. например переставить команды местами, если понимает, что нужные блоки рядышком. после того как контроллер блоки достал, он через механизм DMA (direct memory access) в обход процессора складывает байты в центральную память. когда байты в памяти, через прерывание отдает управление процессору. контроллеров обычно несколько и они друг друга могут заменять.

Прочитав несколько источников по разным архитектурам дисков и их сравнению я пришел к выводу что хорошо то что используется адекватно. Иными словами (E)CKD хорош для z/OS (а в z/OS для IMS и ISAM метода доступа) который построен на использовании именно CKD, а не FBA. A FBA хорош там где вся идеалогия файловой системы построенна на FBA архитектуре. Еще иными словами можно сказать что переделка систем с одного на другое ничего хорошего не даст, да и не возможна. Поэтому Линух на МФ лучше кормить SCSI дисками, а не z/OS-скими (E)CKD, хотя это и возможно. И z/VM с CMS по причине блочности его файловых систем тоже хорошо чуствует себя на FBA дисках, хотя и (E)CKD для них как родные.

Многое на сегодня имеет кросплатформенную унификацию - FICON в своей основе имеет унифицированный стандарт Fiber Channel и как результат разные порты одной и той же FICON карты на MF могут быть сконфигурированны и как FICON и как FCP. Одни и теже дисковые подсистемы одновремемнно используются для разных платформ, имея в своей основе SCSI диски, представляя их МФ как (E)CKD, а другим (в том числе опять же и МФ) как FBA.

Однако тенденция разгрузки цехтральных устройств от ввода-вывода, реализованная на МФ в форме каналов и канальных программ, выполнение которых уже давно есть программная эмуляция на не-МФ-ских системах, просматривается и в других платформах. Функциональность этой тенденции порой разная, но общее тем не менее есть. Это очень удачно подметил Mark в примере с созданием snapshot-ов для разных нужд.

Повидимому локальные диски (пусть даже и SSD) на серверах не имеют будущего в качестве хранилища баз данных. Кстати, в последнем семействе MF, на которых никогда не было локальных дисков именно в форме SSD они таки появились - для узких специальных нужд, например, как дополнительная память страниц. Это конечно не имеет ничего общего с тем что предлагает Дима.

P.S. Получилось несколько сумбурно и не совсем понятно, но хотелось как то подитожить тему разных подходов, в первую очередь для себя. Не судите строго, но критикуйте конечно.

[DropAndDrag]

У нас на работе была проблема - когда программа слишком перегружала диск, другая программа ждала и вываливалась по таймауту (там речь шла о секундах или долях секунды). Пока смежники переделывали софт на более грамотную буфферизацию, решили по-быстрому перенести запись второго софта на другой диск. И это, естественно, полностью решило проблему. Но был ещё третий софт (бэкап), который по ночам создавал туже проблему, а система должна работать 24/7
Фигня, добавили третий хдд.
И - о чудо - проблема НЕ исчезла
Оказалось, что в хоть в системе и 3 хдд, но контроллеров только 2, и когда на один из хдд, подключеномому к контроллеру что-то пишется, второй хдд на том же контоллере ждёт.
На всякий случай - речь идёт о современной дорогой xeon-системе.
Вобщем, пришлось таки переписать софт чтобы он не падал если хдд быстро не отвечает.
Я хочу сказать, узкое место не всегда там, где ожидаешь - кто бы мог подумать, что все упрется в контроллер хдд!

лет 6-7 назад имел аналогичное приключение на одно место.
был прибор, который имел RAID. Я на нем установливал разработанную примочку AGC (automatic gain control). Пока устанавливал этот RAID сдох и я народу предложил установить новый диск, который по объему в 2 раза больше. В один прекрасный день AGC заработало и народ начал тестировать. День проработало и они оставили работать на ночь, а перед уходом домой запустили подсистему переброски файлов (каждый несколько сот мегабайт за 100 минутное измерение). Утром прихожу на работу и нахожу кучу е-майлов о том, что AGC не работает, да еще грохнула компьютер. Прихожу смотрю - компьютер не реагирует ни на какие действия, включая Ctrl-Alt-Del, посмотреть ничего нельзя - одним словом полный пипец! Все вокруг на три буквы не посылают, но вежливо дают понять, что я наделал ...ни.
После длительного разбора полетов выяснилось, что система, которая перебрасывает файлы перебрасывала до 5 одновременно (деятельно гордо заявил, что у них там такой параметр есть и стоит цифра 5). Так что товарищ запустил энту подсистему, она стала читать 5 файлов, да еще и один записывался при измерении, и все встало раком! Так как я был последний, то меня попытались сделать крайним )))
P.s. А ведь я протестировал, что деградации при 2 чтении-записи практически нету, то бишь ссумарная скорость не падает и прибор успевает все записывать
P.p.s Вы думаете, что разработчики системы переброски в конце концов поняли, что выигрыша при открывании одновременно несколько каналов чтения нету из-за пропускной способности сети ...

[Dmitry67]

Дмитрий а может AlwaysOn делать snap clone? т.е. предположим у вас 10 Tb данных в production и вам надо сделать клон PROD to QA для того чтоб протестить какую-то проблему. При вашем подходе вам понадобится 10Tb на PROD и еще 10Tb на QA (а ведь может быть еще DEV/TEST/UAT) и что везде будете совать локальные SSD и потом долго и нудно сливать 10Tb по сетке?
A netapp сделает snapshot за секунду и и при этом snapshot = delta между PROD и QA (т.е. на QA в реальности займет мегов 100 (не TB а Mb).

Не может. Но и способности netapp в данном случае не пригодятся нам, так как у нас QA хоть и хостится в тех же datacenters, но как бы рядом, то есть там свои ESX, свой NetApp, у всего труба пониже, дым пожиже