about NetApp

Ну вот, как я и обещал раньше, дав поднятой маркетинговыми лаунчами пыли осесть, взбутетененной мути – отстояться, а объективным данным и анализам – появиться, начнем мы в этом блоге серию постов про продукт нашего ближайшего “соседа”-конкурента, новинку EMC, системы хранения серии VNX/VNXe.

Напомню, что в январе EMC с большим шумом и беспрецедентным размахом выкатил ряд новинок, и главную – новую линейку систем хранения младшего-среднего “энтерпрайза” – EMC VNX/VNXe, приходящую на смену классическим CLARiiON/Celerra.
Шум при этом был настолько большой и гм-м.. странный по форме, что сразу возникло подозрение, что этим масштабным лаунчем и сценическим шоу пытаются отвлечь внимание от определенных недостатков и “недоработок” продукта.

Следует отметить, что, безусловно, выпуск VNX это большой шаг EMC, причем шаг в правильном направлении. И пусть злые языки сейчас говорят, что EMC, мол, выпустила новый сторадж, “чтобы было как у NetApp”, мы отметем эти реплики с мест как неорганизованные (с). Приятно, конечно, когда мировой лидер взялся реализовать, пусть и с многолетним опозданием, решения, которые придумала и много лет продвигала значительно меньшая компания, тем самым признавая ее приоритет в этом вопросе, и правильность ее пути. Но все же это решение EMC. Что же нового в этих полностью новых системах хранения?

Ну-у, у них теперь крутая интегрированная система управления Unisphere.

А что там в аппаратной части? Как оно вообще, этот новый Unified Architecture? 
Новые процессора, переход на SAS-диски и SAS-интерфейсы к полкам (велкам ту зе клаб, наконец-то). Новые передние панели, очень эффектные :)
…И все?
А вот похоже на то, что и все. Удивлены? Да не то слово.

Но как же, как же, ведь нам обещали новую, прогрессивную, передовую Unified Architecture, нечто по-настоящему новое, оно где? Оно ведь есть?

Ну-у… Давайте посмотрим, что появилось нового.
Слева – классическая Celerra NS, справа – новый VNX.

Может быть я недостаточно фанат EMC (что очевидно), но по моему нам пытаются продать то же самое, но, в лучших традициях ритейла, “теперь в новой, удобной упаковке”, с банановым вкусом. :)

Да, VNX действительно может отдавать данные на дисках по разным, как блочным, так и файловым протоколам, это то, что “у нас в деревне” называется multiprotocol. 
Но Multiprotocol это все же не то же самое, что Unified.
Рядом, но не то же самое.

Это все равно, как если бы некто, с большим шумом объявил бы о ребрендинге и новом, прогрессивном логотипе компании ЗЕЛЕНОГО цвета. Зеленый это экологичность, он несет в себе стабильность, позитивность, дружественность…
- Погодите, – перебиваете вы докладчика – я что-то не понял. Вы говорите “зеленый”, но логотип же – синий?
- Да какая разница, – отвечают вам, зеленый это теперь новый оттенок синего! Главное что он – ЗЕЛЕНЫЙ, новый, и прогрессивный!

Самое печальное в этой истории, что когда такая маркетинговая и сейловая машина, какой располагает сегодня EMC, начнет настойчиво твердить рынку, что зеленый – это новый оттенок синего, а мультипротокольность – это и есть unified architecture, то рынок неизбежно, в конце концов, и сам поверит, что черное - белое (просто плохо освещенное) , зеленое – синее (ну, другой оттенок просто), а Unified Architecture – это собрать пять ящиков под тремя OS в одном шкафу, и продать клиенту по одной накладной.

Давайте все же остановимся на некоторых очевидных недостатках и проблемах для клиента при переходе на VNX/VNXe, видимых, так сказать, с “нашего берега” этой реки:
(Прошу держать в памяти, что я не являюсь специалистом по оборудованию EMC, и что если где-то здесь, или в любом другом посте, где я говорю о продуктах конкурентов, я допускаю неточность или ошибку, не стесняйтесь мне на нее указать, я поправлю это место, спасибо.)

• Полный отказ от “старых” дисковых полок, подключаемых по FC. Невозможность сделать data-in-place upgrade, то есть с сохранением данных на уже существующих дисках. Ну и что, что у вас уже два шкафа с дисками EMC под год назад купленный Кларион CX4 и 24×7 ERP-база на них? Купите еще два шкафа дисков, скопируете, потом старые продадите кому-нибудь.
• Forklift upgrade даже и с VNXe на VNX, как бы ни были похожи аббревиатуры моделей – апгрейд только целиком, никакого data-in-place (с сохранением данных). “Внутри” VNX от VNXe отличаются сильно, не позволяя прямого перехода.
• Для VNXe нет FC как интерфейса подключения. Вообще нет. 
  Да, VNXe это entry level, и использование entry level с FC это, обычно, overkill, но, допустим, у вас есть уже развитая FC-инфраструктура с “большими” стораджами, и вам понадобилось включить в нее небольшой вспомогательный сторадж, для бэкапа-ли, для удаленной реплики, неважно. Включить в FC-фабрику VNXe вы не можете. Просто некуда.
• В VNXe нет FASTcache. Нет и не будет. Увы.
• По-прежнему полностью раздельная архитектура. Отдельно блочный сторадж (под FLARE), отдельно файловый гейтвей data mover (под DART), отдельно Control Station (под Linux), отдельно объектный гейтвей Athmos. С общим, снаружи, управлением под Unisphere. Никакого Unified Target.
• Только файловая дедупликация. Значит нет дедупликации для LUN-ов, например для Datastore под VMFS в VMware. Совсем нет. А для файлов эффективность меньше, чем в случае субфайловой/блочной дедупликации. Кстати для VMware и Oracle по NFS ее нет тоже.
• Множество разнородных софтверных средств для одних и тех же задач. Три разных инструмента для использования снэпшотов (SnapSure (file), SnapView (block), RecoverPoint SE/CDP (block)), три – для репликации (Replicator (file), MirrorView (block), RecoverPoint SE/CRR (block)), два – для локальных клонов (SnapSure (file), SnapView Clones (block)). Все с разными функциональными возможностями и особенностями применения.
• Capacity-based licensing. Низкая цена “на старте” может оказаться совсем не такой низкой, если вам понадобится увеличить емкость (а вам понадобится ее увеличить, это, в нынешнем мире, неизбежно) – готовьтесь платить еще, позже.

В среду читайте перевод статьи блоггера recoverymonkey о вопросах к EMC по поводу запуска VNX, а далее, на следующей неделе, в понедельник и четверг соответственно, мы рассмотрим подробнее каждое семейство, VNXe и VNX, и то как, и чем они собираются конкурировать с системами NetApp.

На интересный факт обратили на днях внимание. Оказывается сегодня Market Cap (“Рыночная капитализация” по-русски), у EMC, если отнять из нее Market Cap VMware, уже меньше, чем у NetApp. При этом NetApp – это, по сути, “вендор одного продукта”, в отличие от “коллекции” EMC, где Symmetrix, Clariion, Celerra, Data Domain, Isilon, Iomega, Avamar, Centera,  etc, etc.

А вот так выглядят темпы роста бизнеса компаний за два года.

Источник: Google

Ничего удивительного, что EMC так нервно реагирует на всякое упоминание слова “NetApp”. ;)

…А про VNX я вам напишу подробнее, когда уляжется поднятая устроенными вокруг него “танцами” пыль, и будет яснее видно детали, ну и когда я таки соберусь дочитать разные технические подробности по продукту, как “за”, так и “против”.

“Умный, честный и партийный. В одном человеке бывают вместе только два свойства из трех” шутили в пору моего детства (кстати шутка обрела второе дыхание в нынешней России).
Или же есть вариант, особенно для IT -  “быстро, хорошо и дешево”.

EMC, кажется, нашла еще один вариант ;)

Я бы, на месте NetApp, не упустил бы возможности оттоптаться ;)

Продукт, о котором долго говорили, результат скрещения жабы с мотоциклом Celerra и CLARiiON, настоящего (еще более настоящего;) Unified Storage от EMC, базирующегося на файловой системе shenanigan-ского блочного стораджа – VNX.

Да уж, давайте, давайте, заждались (потирает ручонки), наконец-то посоревнуемся за пользователей всерьез, без глупого лечилова про “настоящий fibre channel”.

Источник: http://www.theregister.co.uk/2011/01/04/emc_vnx_unified_storage/

Подробности, по всей видимости - 18.01.

PS. Интересно, съест ли свою шляпу Чак Холлис? ;)

UPD: Подробности нашлись на SearchStorage

UPD: Да, вернулся в эфир чуть раньше, сначала предполагал запостить это 17, в понедельник, накануне официального анонса, но так как прошла утечка, и народ в интернетах загомонил, решил не ждать, да и вам интереснее.

“Какой пассаж!”, как говаривала гоголевская дама. Столько ведер презрения было вылито на NetApp Чаком Холлисом за эти три года за использование им в своих системах блочного протокола поверх “файловой системы”, и ради чего?

Ради того, чтобы три года этой ругани спустя, потеряв много больше лет, на протяжении которых NetApp совершенствовал свою систему, EMC пришел в своих продуктах, по сути, к тому же самому решению – блочному протоколу поверх нижележащей файловой системы.

Ирония судьбы.

У одного из нетапповских блоггеров увидел хорошую статью, перевод фрагмента которой хочу опубликовать у себя.

Одной из самых популярных “страшилок-говнилок” в отношении NetApp является пугалка о том, как неэффективно расходуется пространство на системах хранения NetApp, как мало получается usable space из данного объема raw. Пожалуй, по популярности эта “говнилка” у наших конкуретнов идет сразу за страшилкой о фрагментации (и ее мифическим “катастрофическим влиянием на производительность”), и за пугалкой про “эмуляцию LUN поверх файловой системы”. Я уже писал ранее про то, как обстоит дело с первой, и рассказывал как устроена организация данных на “низком уровне” в WAFL, объясняющая ситуацию со со второй.

Пришла пора разобрать где правда в третьей.
Итак, правда ли, что usable space на NetApp получается значительно меньше на том же объеме raw, например при сравнении с “более традиционными” системами?

Давайте разберем пример, хоть и не исчерпывающий, но довольно зрелищный.

Continue reading ‘О расчете дискового пространства: NetApp FAS и EMC NS – что стоит за FUD (часть 1)’ »

Наверное нет лучшего дня, чтобы заняться распространением FUD-а и слухов о конкурентах. В случае чего всегда можно сослаться на “день дурака”. :)
Вот уже несколько недель в прессу просачиваются слухи о грядущем большом изменении в продуктовой линейке, и даже берите выше, в общей стратегии систем хранения midrange компании EMC.
Я уже не раз писал в блоге о том, что одним из главных аргументов специалистов EMC в своеобразном “стратегическом споре” с netapp-овцами является аргумент “у нас, в отличие от вас - настоящий Fibre Channel. Наши стораджи - настоящие блочные устройства, без этих ваших всяких “виртуляций-эмуляций” поверх файловой системы, и связанных с этим накладных расходов, поэтому EMC будет всегда-всегда быстрее паапридилению“.
На что со стороны NetApp регулярно приводится возражение, что “вы ее просто не умеете готовить”, и что “поверх файловой системы” можно сделать сторадж, который будет “лучше чем настоящий Fibre Channel“.

И что же мы видим в результате? А вот что. Источник, правда, желтоватый, однако есть косвенные подтверждения и не только из уст The Register.
То есть, по сути, для тех, кому лень читать текст по ссылкам, EMC рассматривает вариант перехода в моделях midrange (семейства Clariion CX (SAN) и Celerra(NAS)) на некую виртуализованную платформу (предварительное и условное имя - V-CX), которая будет, сюрприз, виртуализванным универсальным хранилищем поверх файловой системы, заменив собой и Celerra, и Clariion. Злые и ехидные языки уже пустили в обиход имечко “Celerron” ;)

“Ребята в EMC, передайте уже кто-нибудь Чаку ваш текущий roadmap по продуктам, нехорошо так издеваться над заслуженным человеком.” (с)

Тем временем, NetApp недавно отчитался о взятии новой высоты. В октябре 2002 года, выпустив модели серии FAS900 NetApp начал, как мы сейчас понимаем, фундаментальный отраслевой прорыв, под названием “Unified Storage”, производство и поставку универсальной, мультипротокольной системы хранения, которая обеспечивает доступ к хранимым данным по любом из доступных протоколов, так как может работать как в SAN-сети по протоколам FC или iSCSI (а недавно уже и FCoE), так и как NAS-устройство, с файловым доступом через Ethernet, по протоколам NFS или CIFS.
То есть неважно, что за задачу вы решаете, какие именно способы доступа к данным вы выбираете, одна система хранения хранит и обеспечивает доступ к ним всем. Сама по себе, без необходимости установки “шлюзов”, “гейтвеев” и иных подобных устройств, для “конвертации” протоколов из одного в другой (то есть, например, из Clariion в Celerra при помощи Data Mover у EMC, или с помощью NAS gateway у HP EVA).
Такая концепция, которую впервые реализовал NetApp, получает все большее распространение и популярность в отрасли.

А в конце марта NetApp объявил о продаже 150 000 unified-систем, за эти прошедшие 7 с половиной лет.
И это уже совсем не первоапрельская шутка :)

На днях EMC выкатило на тесты SPECmark (тесты производительности NAS enterprise-уровня), впервые с 2007 года, свой “суперболид” на базе симметрикса и “всех порвала!!!11″.
Впрочем, как выяснилось довольно скоро, не то чтобы совсем порвала, а так, понадрывала по краю ;)
По этому поводу блоггеры NetApp вовсю ехидничают.
Судите сами:
EMC Symmetrix V-MAX, 4x V-engines, 264GB cache total
96 штук 400GB EFD flash drives (это EMC-шные SSD) в двух RAID-1
3 штуки (2 active + 1 passive) Celerra NS-G8 Datamovers в качестве NAS Gateway, 8GB cache в каждой.
24-портовый коммутатор FC, чтобы всю эту кухню пересоединять между собой
Наддув, впрыскивание закиси азота, ксеноновые фары и брызговики Sparco.

И все это счастье сисадмина, стоимостью не менее чем 6 миллионов долларов в ценах американского лиспрайса набирает аж 110621 спекмарковских попугаев по SPECsfs2008 в NFS (и 118463 в CIFS, которые никто почти и не меряет из участников).

Круто типа.
Но при этом еще в прошлом году NetApp публиковал результаты FAS6080, с ценой проекта едва ли вполовину EMC-шной, на обычных дисках (не SSD), и даже без Performance Accelerator, показавшей 120011 спекмарковских попугаев.
А результат в районе 60 тысяч, то есть вполовину EMC-шного “устройства для завоевания превосходства в датацентре” показывает довольно таки средненькая midrange FAS3160, причем при использовании PAM делает она это на всего лишь 96 дисках SATA (!)

Я уж не говорю, что по абсолютной величине их обгоняет, например система производства Huawei Symantec ;)

Материалы по теме:
Все опубликованные результаты SPECsfs2008
Ник Триантос: “Как потратить побольше, а получить поменьше”
Вон Стюарт: “Бенчмаркинг-жульничество*”
* “Жульничество”(Shenanigans) - один из любимых терминов Чака Холлиса, блоггера EMC, обычно в отношении NetApp.
Комменты к обоим вышеприведенным постам не только доставляют, но и служат интересными источниками подробностей, рекомендую.

Сегодня я бы хотел провести для вас своеобразный "мастер-класс говнилок", или, если угодно, "сеанс черной магии", разумеется "с последующим ее разоблачением". Я воспользуюсь для этого статьей небезызвестного блоггера Чака Холлиса, почти официального "говнильщика" компании EMC. В части "разоблачений" мне поможет Вэл Берковичи, блоггер NetApp, некоторое время назад сделавший показательный разбор одного из постов Чака.

Чак выбрал своей темой сравнительный анализ результатов получения Usable Space из Raw на трех разных платформах хранения - EMC Clariion, HP EVA и NetApp FAS. Ну за EVA, я надеюсь, вступится еще кто-нибудь, я же разберу двух оставшихся, тем более что я по EVA не спец, однако уверен, что и там вполне могут быть схожие "результаты".

Вэл очень показательно сравнивает манеры, при проведении такого сравнения с поведением фокусника. Сначала нам показывают нечто вполне обычное и привычное. Колоду карт. Кролика и шляпу. Женщину в ящике ;) Мы осматриваем их, и вынуждены согласиться, что да, никакого подвоха тут нет (обычно уже на этом этапе что-то не так, и хитрость уже спрятана, чтобы вовремя сработать).

На втором этапе фокусник превращает рассмотренные нами обычные предметы в что-то необычное. Что-то исчезает, что-то видоизменяется, и так далее. Вы потрясены.

Тут все зависит от того, хотите ли вы быть одураченными. Если да, как обстоит дело в большинстве случаев, вам ничего не остается как согласиться с фокусником: "Да все так, кролик исчезает в шляпе, а женщина перепилена", даже несмотря на то, что в глубине души вы и понимаете, что вас где-то провели. Но ведь вы внимательно следили!

В свое время, в каждом выпуске журнала “Юный Техник”, известный фокусник Эмиль Кио давал описания какого-нибудь незамысловатого фокуса (ну у него их много в запасе было), с объяснениями "как".

Попробую и я показать вам в каком месте у Чака начинается "ловкость рук".

Итак, начало, The Pledge, "предъявление предметов".

Чак предлагает нам сравнить величины Usable Space на каком-нибудь простом и знакомом примере. Например инфраструктура хранения для MS Exchange.

Возьмем для примера шляпу диски FC 146GB, определим, что мы хотим получить на выходе пространство, равное емкости 120 дисков (около 17,5TB), и посчитаем, сколько дисков нам придется купить для системы, чтобы эти условия соблюсти.

Мы берем руководства Best Practices по установке для соответствующих систем, и начинаем, оперируя ими, рассчитывать пространство, "делать сайзинг" как это называется у нас.

Повторюсь, я не слишком большой спец в области конфигурирования EMC, поэтому я просто возьму анализ для CX4 самого Чака. Я не стану переписывать тут весь его пост, за подробностями можно пройти непосредственно к нему, покажу лишь сам принцип. Итак, перед нами стоит задача получить на выходе usable-емкость 120 дисков на 146GB. Что добавится к этой величине?

Диски hotspare - EMC рекомендует иметь 1 диск hot spare на каждые 30 дисков данных.

Пространство для snapshots - возьмем эту величину равной 10% от usable

Секторный оверхед - Clariion также как NetApp FAS использует увеличенный до 520 байт сектор, то есть примерно 1.5% к пространству usable.

Но что это? Внимательный взгляд уже видит первую ловкость. Отчего это Чак берет в качестве типа RAID для такой большой системы - RAID-5?

Даже если вас не убедила моя "дюжина ножей"(пост раз и пост два) в спину RAID-5, довольно будет и того, что это не рекомендует даже сам EMC в тех самых Best Practices, на которые сам же Чак Холлис и ссылается:

страница 15, документ #H4060, Oct. 2007:

It is generally accepted that RAID 1/0 is a better choice for random-write environments like Exchange

В том числе это так и для DMX (стр. 7-49):

http://www.emc.com/collateral/hardware/solution-overview/h4067-microsoft-exchange-server-symmetrix.pdf

As a matter of Best Practice, EMC generally recommends RAID1 to be the primary choice in RAID configuration for reasons of reliability and availability and performance for high-end deployments of Microsoft Exchange Server.

Вот он, трюк. Сейчас посмотрим, что получится в результате.

Кроме этого, Чак еще пару раз "забывает" о некоторых моментах, так, например, говоря о рекомендации делать right sizing на 10% для дисков в RAID на NetApp, для того, чтобы, при необходимости, можно было ввести в RAID диск слегка отличающийся по "геометрии", например спустя несколько лет, если поставляемые на замену диски отличаются от оригинальных в количестве секторов, он напрочь "забывает" это учесть в своем расчете для CX4, несмотря на то, что на это прямо указывается в Best Practices EMC.

Также не забудем и про пресловутый Vault на первых 5 дисках. Если в случае использования RAID-5 у нас были шансы использовать этот маленький пятидисковый RAID-5 в составе системы, также целиком выполненной в RAID-5, то в случае RAID-10 деть этот небольшой RAID-5 нам некуда, придется не использовать его для данной задачи вовсе.

Использовать же эти 5 дисков в составе большого RAID-10 нельзя, так как Vault на них уменьшает их "аппаратную геометрию", и они становятся "несовместимыми" по размерам с остальными дисками системы. То есть минус 5 дисков целиком.

Но для нашей большой системы это уже детали в единицы процентов (для системы меньшего размера они уже не будут столь незначительными). Оставим их, учтя в общем расчете, и только.

Что же у нас получилось?

А вот что:





Разительная разница по сравнению с цифрами, приведенными у Чака, не правда ли?

"Ловкость рук, и никакого мошенства".





 

Теперь займемся нашим NetApp FAS.

Исходные данные те же.

120 дисков по 146GB емкости в Usable, сколько должно быть в Raw?

Исходный ход расчета Чака оставим без изменений, но будем опять внимательно смотреть "за руками".

Вот оно!

One thing is extremely clear — running out of snap reserve looks to be a very bad thing in a NetApp environment — there’s no place to put an incoming write, usually resulting in catastrophic application failure.  By comparison, other approaches (e.g. CX4 and EVA) simply stop trying to capture before-write data if you run out of reserve — the application itself continues to run.

…

It is recommended to have a 100% space reservation value set for volumes hosting LUNs containing Exchange data.

Разумеется в таком анализе не обойдется без традиционной спекуляции на тему 100% LUN space reservation. Как-то даже слишком предсказуемо.

Обязателен, неизбежен и абсолютно необходим ли 100% space reservation, как необходимо отдать 100% от объема data disks при создании RAID-10?

НЕТ.

Вы не можете уменьшить количество дисков, уходящих под "зеркало" в RAID-10, в котором Usable еще до всех "вычетов" всегда будет менее 50% от Raw.

Однако можете уменьшить количество места, отдаваемое под fractional LUN reservation в NetApp FAS, так как его уменьшение не ведет к неработоспособности.

Я уже останавливался ранее на том, что же скрывается за fractional (LUN space) reservation.

Скажу честно, тема непроста, но понять ее можно. Вот, если вкратце, на пальцах:

LUN space reservation это место, выделяемое и резервируемое на томе в том случае, если вы планируете использовать snapshot для LUN,и есть риск, что значительная часть объема этого LUN будет перезаписана. В этом случае резервирование пространства размером с весь LUN гарантирует нам то, что можно будет создать snapshot с этого LUN и место для нормальной работы с этим LUN-ом еще останется.

По умолчанию, руководствуясь правилом "прежде всего - не навреди" Data ONTAP действительно предлагает наиболее "консервативную" установку, в виде 100% reserve, гарантирующую, что даже если админ совсем ничего не понимает, и ставит систему Enter-ом, соглашаясь со всеми дефолтными настройками, то ничего смертельно опасного для его данных при работе не произойдет.

Означает ли это, что никаких других возможностей не предусматривается? Нет, не означает.

Можно ли не использовать 100% LUN space reservation, и чтобы при это все работало? Да, запросто.

Какие еще возможности есть? Можно, например, автоматически увеличивать размер тома, на котором расположен LUN, с тем, чтобы места хватало и на LUN, и на создаваемые Snapshots. А можно настроить автоматическое удаление старых снэпшотов, при создании более новых, если им не хватает места.

Ну и, наконец, если места не хватило, то предусмотрена возможность корректного автоматического размонтирования LUN-а, на котором невозможно продолжать запись.

И все это - без необходимости резервировать 100% от usable space под LUN space reservation.

Давайте посчитаем по нашей методике raw space, взяв желаемый usable добавим к нему все "вычеты", "оверхеды" и "резервации", добавим диски parity RAID из расчета 2 диска на каждые 14 дисков (RAID-DP), и, наконец, hot spare (два на первые 100, и по два на каждые следующие 84), и посмотрим что получилось (все дробные величины округлялись в большую сторону до целочисленных значений, указанные на диаграмме значения показывают доли секторов диаграммы и не всегда равны процентам в таблице).





Для желающих поиграться - прикладываю мою табличку, где я все это рисовал.

EMC_vs._NetApp.xlsx

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

1. Представить себя как "независимое лицо", незаинтересованное в определенном "предвзятом" результате. Например проведите сравнение параллельно для нескольких вендоров.
2. Продемонстрировать все исходные материалы, упирая на их доступность.
3. Всегда аппелировать к вендорским Best Practices, пусть даже отдельные части их и будут проигнорированы, а сами они могут быть "outdated", устаревшими. Мало кто полезет проверять все подробности в 150-страничном PDF-е, в лучшем случае прочтет указываемое вами предложение в тексте, зачастую без контекстной связи.
4. Всегда сравнивать системы в выгодном для себя контексте. Ваша система имеет низкую производительность? Сравнивайте на задачах архивного хранения и резервного копирования. Система высокопроизводительна, но дорогостояща? Сконфигурируйте минимально возможную, пусть и неприменимую в реальной жизни конфигурацию. Малопроизводительна, но дешева? Активно пользуйтесь сравнением соотношения price/performance. Владея инициативой при написании документа - заставьте противника обороняться на неудобном для него поле.
5. Не забудьте о психологическом давлении и субъективности восприятия. Хорошее название для сравнительного документа "Вся правда о…". Почаще упоминайте "свободность" и "открытость" (“хорошо!”) в пику "проперитарности" и "закрытости" (“плохо!”).
6. Проводя в тексте нужный трюк, постарайтесь отвлечь от него внимание, например ссылками на какие-либо документы, или цитаты авторитетов. Актуальность их обычно не проверяется. Хорошо работают графики таблицы, иллюстрирующие ваши выводы, тем боле, что чаще всего перепроверять данные никто не полезет.
7. Отлично работают: “правильная” группировка результатов, а также маленькие хитрости, типа смешивания единиц измерения, неуказание единиц, нелинейная шкала отображения для графиков, и так далее.