Немного не хватает данных - например, о режиме работы бортового RAM-кеша контроллера, но давайте попробуем разобрать то, что есть:
Если на том массиве, на который производится запись, включена CacheCade, то сильно падает производительность.
CacheCade только чтение - очень сильное падение. Скорость обмена на уровне флешки.
Ничего удивительного - запись идёт непосредственно на харды. Если при этом ещё и выключен RAM-кеш контроллера (а такое может быть, если "механически" воспользоваться рекомендацией выключать его в случае использования SSD на контроллере), то всё грустно - например, Ваш R1 в таком разе будет писАть со скоростью одиночного харда.
Ситуацию усугубляют приличные издержки со стороны VMFS - она грешит множественными рэндомными операциями записи служебной метаинформации LUN`а, что для описанной выше "голой" записи на хард и без кеширования бортовой памятью чревато ощутимыми тормозами: головкам одиночного диска приходится метаться, как коробейнику в базарный день.
CacheCade на запись - улучшает ситуацию.
Это естественно - запись на SSD шустрее таковой на харды. Получаем промежуточное кеширование записи на более быстрый носитель перед окончательным перемещением данных на харды.
CacheCade отключена - максимальная скорость обмена.
Вот это несколько странно.
С одной стороны, ситуация должна быть эквивалентна первому случаю - CC(read).
Но с другой стороны "отсюда плохо видно(с)": если при включенном СС(read) использовали WТ-режим кеша на контроллере, а при отключенном переходили к WB, то тогда всё бьётся.
Как дополнительный фактор теоретически возможно влияние на запись даже и СС(read), если при этом происходит обновление "горячих блоков" данных на ssd-кеше путём копирования их с HDD - такая конкуренция за seek`и способна повлиять на скорость записи и показать эффект её увеличения при полном отключении СС для тома-цели.
При CacheCade на запись пользователи жалуются сильные тормоза в системе.
Ну если не считать, что пользователям никогда не бывает хорошо (или их жалобы связаны не с дисковым обменом, а, например, с сетевым , или вообще с подводными граблями 6-й Сферы), то могу отметить, что достаточно интенсивный режим записи на SSD - безотносительно, СС-том это, или просто SSD-LUN с данными - способен давать "фризы" с падением трафика просто в силу того, что у SSD перекос между R и W может достигать совершенно неприличных размеров не в пользу последнего.
Собственно, именно это обуславливает известные рекомендации использовать в продакшене ентерпрайзные SSD с конденсаторной защитой их собственного кеша (что позволяет не отключать его ради надёжности, тем самым пришпоривая запись на них).
Плюс один неочевидный момент: Write Amplification, являющееся основной причиной тормозов на запись у SSD, преодолевается внутриSSDшными ухищрениями - путём записи новых данных (а так же и ПЕРЕзапись старых) в "чистые" блоки флеш-памяти, что избавляет нас от WA. Соответственно, старые блоки помечаются у контроллера SSD как неактуальные и периодически очищаются механизмом BGC.
При этом интенсивная запись очень быстро исчерпывает запас "чистых" блоков флеша (BGC просто не успевает очищать неактуальные блоки) - так называемую Wear Leveling Area, оставляемую производителем в к-ве нескольких процентов от ёмкости носителя - и запись начинает производиться с гораздо меньшей скоростью из-за упомянутого WA.
В случае использования SSD "классическим" образом, для создания рейд-группы для данных, этот эффект можно скомпенсировать, оставляя неразмеченным "хвост" группы в несколько десятков процентов - тогда такой вот "самодельной WLA"хватает, чтобы смягчить вышеупомянутые эффекты при записи и дать механизму BGA возможность "успеть" почистить побольше неактуальных блоков.
Так вот для СС у нас нет возможности оставить неразмеченный "хвост" SSD для "самодельной WLA" - под СС используется ВСЯ ёмкость SSD.
Соответственно, интенсивная работа СС на запись подчиняется тем же самым законам, что и обычная SSD-группа для данных - резкое усиление WA, причём не компенсируемое увеличенной WLA.
Собственно, именно поэтому я использую СС исключительно ради кеширования чтения - его, чтение, закешировать гора-а-ааздо труднее, нежели запись (та кешируема много где - буфер приложения, кеш ОС, кеш контроллера, кеш дисков). А при нужде в очень быстрой записи использую "честные" SSD-группы из нескольких носителей (по возможности ентерпрайз-класса, с конденсаторной поддержкой их кеша) на быстрых контроллерах... и с непременным "искусственным" увеличением WLAпротив заводского методом неполной разметки рейд-группы.
Вот вкратце так. Если что-то поможет Вам, натолкнув на мысли, буду рад.
UPD: если уж Вам ну совсем никак без ССwrite, то можно слегка "объегорить" WAпутём линейного масштабирования - соберите СС-группу из бОльшего к-ва SSD (на сколько хватит свободных каналов контроллера/экспандера).