среда, 24 июня 2015 г.
СХД начального уровня от Lenovo - S2200 и S3200
Новый лидер от HP - 3PAR 20000
пятница, 9 ноября 2012 г.
Пополнение у СХД начального уровня IBM–Storwize V3700
На этой неделе в IBM сделали еще один шаг к созданию целостной линейки систем хранения данных. Была анонсирована система хранения IBM Storwize V3700, которая, как явно следует из названия, является более бюджетным вариантом Storwize V7000. Действительно, V7000 или V7000 Unified далеко не всегда могут попасть “в бюджет” заказчику, хотя их функционал и идеально вписывается в проект. Поэтому выпуск более бюджетного варианта является отличным ходом!
Давайте посмотрим, что именно IBM предлагает заказчикам V3700:
- Красивый :) интерфейс! Он уже стал привычным для владельцев таких СХД как V7000, SVC или XIV, теперь можно им пользоваться в системе с ценой меньше 20k$. Интерфейс удобный (если нет желания работать в CLI), если никогда не встречали его раньше, посмотрите ролик в этом посте.
- Виртуализация внутреннего дискового пространства. Вместо традиционных RAID-групп используются дисковые пулы.
- Выделение дискового пространства по мере необходимости – thin provisioning. (Когда же будет доступна рекламация дискового пространства?)
- Функционал FlashCopy в том варианте, в котором он есть в “старших” системах. До 64х снимков на систему.
- Производительность – по формальным показателям V3700 опережает DS3500 (хотя и отстает по максимальному объему дискового пространства).
- Миграция данных с имеющихся систем хранения (по FC). Миграция возможна только в одну сторону – для миграции данных с V3700 куда-нибудь еще придется использовать сторонние средства. Хотя, кто же захочет мигрировать данные на другую систему?!
- Поддержка до 120 дисков 2.5” или до 60 дисков 3.5”. К контроллерной полке можно подключить до 4х полок расширения. И контроллерный модуль и дисковая полка занимают в стойке 2U и поддерживают либо 12 дисков 3.5”, либо 24 диска 2.5”. Миксовать полки можно в любой последовательности.
- Поддержка 4х портов 1Gbit iSCSI “в базе” (по 2 порта на контроллер).
- Дополнительно можно установить в каждый контроллер интерфейсную плату. Это может быть либо 4 порта 1Gbit iSCSI, либо 2 порта 10Gbit iSCSI/FCoE, либо 4 порта 8Gbit FC. Разумеется в оба контроллера нужно устанавливать одинаковые платы.
- Возможность апгрейда кэш памяти – вместо “стандартных” 4GB на контроллер можно поставить 8GB (16GB на систему хранения).
Кстати, обратите внимание, что SAS порты имеют интерфейс mini SAS HD:
Но, помимо стандартных возможностей, есть и перспективы, о которых также было объявлено. Чего стоит ожидать от V3700 в некоторой перспективе (не факт, что все это действительно случится – это только “statement of direction”):
- Поддержка SAS подключения к серверам. Самое интересное, что данная поддержка будет включаться бесплатным апгрейдом микрокода. Сами SAS порты уже есть на контроллере (см. картинку выше) – только один из них используется для подключения дисковых полок, а остальные в настоящее время не задействованы.
- Поддержка Easy Tier – динамическая миграция “горячих” блоков данных с обычных дисков на SSD для повышения производительности системы.
- Поддержка репликации на удаленную СХД. Действительно, сегодня без этого даже система начального уровня выглядит “недоделанной”! Будет ли поддержка репликации на V7000 или на SVC пока не известно, но это стало бы дополнительным плюсом при выборе V3700.
- Поддержка до 2040 снимков (FlashCopy) на систему.
Но ведь не может же быть все так прекрасно? Наверняка же есть какой-то подвох и V3700 не умеет что-то очень важное и нужное? Конечно, система начального уровня не может обладать всеми возможностями старших братьев, иначе она и не стоила бы дешевле.
Чего же IBM НЕ предлагает владельцам V3700?
- Компрессия – если хочется компрессии, то потребуется либо отдельный appliance (и они у IBM конечно есть), либо V7000 или SVC.
- Виртуализация сторонних СХД. Хотя миграция и поддерживается, но виртуализации в V3700 не будет. Если хочется расти, то можно подключить V3700 к V7000 или SVC.
- Объединение систем в кластер.
- Поддержка NAS – unified системы не ожидается.
Критичны ли эти “не” для малого бизнеса, в котором V3700 будет первой системой хранения данных? Интерес может представлять unified и компрессия, но обе эти возможности далеко не бесплатны, поэтому я не уверен, что они стали бы популярны в связке с V3700.
Система, на мой взгляд, получилась очень интересная, особенно когда все планы по расширению функционала будут реализованы!
V3700 доступна к заказу с 23.11.2012 – обращайтесь к нам и наши инженеры помогут подобрать систему с необходимыми характеристиками для ваших задач. Мы можем проанализировать имеющуюся нагрузку на дисковую подсистему (и не только) и поможем правильно выбрать систему, чтобы она оправдала все ожидания!
пятница, 8 июня 2012 г.
IBM DS3500/DCS3700: радикальные изменения
Как многие вероятно уже слышали, у IBM в этот понедельник прозвучало множество анонсов в области систем хранения. В той или иной степени были затронуты практически все линейки. В этой заметке я коснусь только лишь младших систем – DS3500 и DCS3700.
Большинство новинок носит принципиальный характер. Итак, новинки:
- дисковые пулы (Dynamic Disk Pooling, DDP);
- выделение дискового пространство по мере необходимости (Thin provisioning);
- новая технология мгновенных снимков;
- поддержка VAAI;
- поддержка ALUA;
- временные лицензии.
В чем плюсы, как это работает и что с этим всем делать? Попробуем пройтись по всем новинкам.
Динамические дисковые пулы.
Вместо привычных RAID массивов (Array) и томов на них (Volumes, LUNs), мы объединяем диски в большой пул и уже на этом пуле “нарезаем” тома нужного нам размера. Мы больше не привязаны к размерам конкретного массива, поэтому нам не нужно планировать массив так, чтобы наиболее эффективно его заполнить – все равно черпаем из “общего” котла. Нет ни выделенных дисков четности, ни выделенных hot-spare дисков.
Ну хорошо, схожие технологии мы видели и у других производителей, а в чем же отличие? Давайте посмотрим, как работает DDP. Каждый диск разбивается на 512МБ “дольки” (D-Piece) – см. рисунок ниже. Когда нам требуется выделить место из дискового пула для конкретного тома, система выбирает 10 таких “долек” с разных дисков (выбирает она так, чтобы выровнять занятый объем). Выбранные дольки объединяются в RAID-6 (8D+P+Q) и уже этот страйп (D-Stripe) размером 4ГБ и становится частью нашего тома с данными. D-Stripe для одного тома располагаются по разным дискам, обеспечивая, таким образом, распределение данных по всему пулу:
DDP не становятся заменой какой-либо технологии – можно использовать только один пул, можно использовать несколько пулов в одной системе, можно использовать и классические RAID-группы, и пулы вместе. Так как пулы по производительности все-таки ближе к RAID-6 и максимальную эффективность показывают на дисках NL SAS, то данные для приложений, критичных к скорости можно вынести, например, на отдельные RAID10.
В случае сбоя одного из дисков в пуле, происходит восстановление данных на оставшиеся диски. За счет того, что в восстановлении участвует большое число шпинделей, оно происходит с большей скоростью и оказывает меньшее влияние на производительность массива. Вместо выделенных hot-spare дисков резервируется соответствующее свободное место в пуле (примерно так, как это реализовано в HP EVA). Можно зарезервировать до 10 дисков (или до 20% объема пула). Вот как изменяется время восстановления в зависимости от числа дисков в пуле по сравнению с перестроением классического RAID6:
На 192х дисках различие превышает 5 раз! А при временах порядка 10 часов это весьма заметно. Не стоит забывать, что при восстановлении классического массива деградация производительности также весьма велика:
Хорошо видно, что во время ребилда диска в большом пуле, производительность приложений будет страдать заметно меньше (особенно если не ставить целью провести перестроение максимально быстро).
Конечно, раз уж речь зашла о производительности, то хочется сразу уточнить, а насколько такая новая технология “портит нам жизнь” в плане этой самой производительности? Результаты показывают, что максимально “страдают” операции случайной записи и последовательного чтения(~15%); случайное чтение же ухудшается всего на 6%, а последовательная запись даже улучшается. Такие эффекты заметны в “синтетических” тестах на 192х дисках в пуле. Если же количество дисков меньше, то и различие в производительности приближается к нулю.
Еще один замечательный плюс от DDP – возможность добавления дисков в пулы. Вы скажете что в RAID тоже можно добавить дисков? А сколько “за один раз”? А чем это чревато с точки зрения производительности? Вот именно – лучше этого на обычном массиве не делать. При добавлении же в пул новых дисков, происходит миграция незначительного числа “D-Piece” на новые диски, что не оказывает, в свою очередь, существенного влияния на производительность системы.
Таким образом, динамические пулы дают нам отличную замену для RAID6, позволяя объединить большое количество дисков, обеспечивая высокую производительность, простоту управления и высокую защищенность.
Thin provisioning.
Данная технология уже хорошо всем известна, но теперь она появилась и в младших СХД IBM. Причем появится и у тех, кто год назад стал владельцем системы DS3500. Единственное “но” – thin provisioning работает только на динамических томах! Поэтому “поиграть” на системе, не создав заранее дисковый пул, увы, не получится. Плюсы у thin provisioning очевидны – не нужно задумываться о точности выделения дискового пространства. Можно выделить немного больше, а по факту на дисках будет занято ровно столько, сколько данных было записано. На самом деле, с шагом 4ГБ конечно – выделение дискового пространства осуществляется в терминах D-stripe. Экономия от использования технологии thin provisioning может быть колоссальна – проверьте на своих системах, сколько незанятого места теряется впустую?
Новые мгновенные снимки.
Еще одна давно ожидаемая возможность. Долгие годы владельцы систем IBM DS3000/4000/5000 вынуждены были мучиться с восстановлением данных из снапшота (невозможно сделать операцию rollback, вернее возможно, но очень “некрасиво”). И вот, новых снапшотов можно сделать не просто заметно больше, но и можно быстро “откатиться” из снапшота на исходном томе. Также появляется возможность использовать группы консистентности, а это очень полезно, когда данные одного приложения находятся на различных дисках:
Rollback в рамках группы консистентности также работает! Несомненным плюсом стала оптимизация операций копирования исходных блоков в рамках технологии Copy-on-Write. Если раньше для каждого снимка происходило копирование исходного блока данных, то сейчас копия делается только единожды. Это существенно снижает эффект от деградации производительности при использовании мгновенных снимков. Падение производительности для “классических” CoW снимков может составлять десятки процентов. Сейчас эта проблема должна быть решена, что позволит использовать снимки и в более нагруженных средах.
Поддержка технологии VAAI.
Многие рассматривают VAAI исключительно как средство повышения производительности в среде VMware, но я бы скорее делал бы упор не на скорость выполнения отдельных операций (хотя это, без сомнения, приятно), а на разгрузку хоста от “лишней” работы и разгрузку сети хранения. Клонирование виртуальной машины с использованием VAAI может быть закончится и не на много быстрее, но зато канал ввода-вывода между сервером и СХД будет загружен в разы меньше и наше клонирование не окажет пагубного влияния на остальную инфраструктуру (особенно если мы используем 1Gbit iSCSI). В рамках VAAI поддерживается – блокировка экстентов в VMFS, write zeroes (write same) и extended copy (клонирование VM, Storage vMotion). Время выполнения операций с VAAI и без оного (кликабельно):
Поддержка ALUA.
Наверное многим доставляли проблемы active/passive пути? А потом еще приходилось вручную возвращать диски на “свои” контроллеры после каждого сбоя. Благодаря ALUA (Asymmetric Logical Unit Access) об этих неприятностях можно спокойно забыть. Чтобы было более понятно, пара картинок. Вот как работает multipath в DS3500 сегодня:
А вот как он будет работать в новой прошивке:
Наибольшие преимущества от ALUA заметны в кластерной среде, когда время failover при проблемах на контроллере играет критичную роль. Поддержка ALUA есть во всех ключевых операционных системах.
Временные лицензии.
До настоящего момента было очень сложно оценить “полезность” дополнительного функционала систем DS3500. Если мгновенные снимки можно было попробовать, то репликацию проверить было фактически невозможно. Решение о покупке (с бюджетом, сопоставим со стоимостью контроллерного модуля) нужно было принимать на основе обещаний, книжек или еще чего-то там. Теперь можно будет установить временную лицензию на 90 дней и проверить работу в своей среде, со своими приложениями. Указанных 90 дней, в принципе, должно хватить не только чтобы проверить функционал, но и для того чтобы заказать постоянные ключи и дождаться их прихода.
Вот такие замечательные новинки были представлены IBM для систем начального уровня. Я, честно говоря, ожидал немного большего, но и это уже очень и очень хорошо. Развитие систем не останавливается – будут и другие новшества, но позднее. Все, о чем я написал, будет доступно в прошивке, которая анонсирована на 15 июня. По факту, скорее всего, скачать ее можно будет на несколько дней позднее, но шанс попробовать все возможности уже в этом месяце безусловно есть!
понедельник, 28 мая 2012 г.
EMC VNX–что день грядущий нам готовит
Я уже писал про новости в high-end системах EMC, но гораздо более интересным для меня является анонс новых возможностей систем среднего уровня – VNX. И дело не в том, что такие системы гораздо больше распространены и в разы больше продаются. Речь о тех технологических возможностях, которые в них появятся. Да, несмотря на анонс, их пока нет и ждать их стоит во втором полугодии 2012. Так что же было объявлено?
Если кто-то вникал, как именно работают пулы (pools) в VNX, то наверняка обратил внимание на “магические” числа. Это, в частности, число “5” для RAID5 и “8” для RAID-6. Дело в том, что при создании пулов, именно такой размер RAID-группы всегда старается выбрать система. Конечно, если дисков недостаточно, то пул все равно будет создан, но в одной из RAID-групп дисков будет недостаточно (или слишком много), а это скажется на равномерность нагрузки. Подробности можно прочитать вот в этой замечательной заметке, либо в ее переводе здесь. Таким образом, для RAID5 эффективность использования дискового пространства составляет 80%, а для RAID6 – 75%. В новой версии было принято увеличить размер дисковых групп – для RAID5 он может составлять 8+1 (эффективность 88.9%), а для RAID6 даже 14+2 (эффективность 87.5%). С одной стороны, это позволит несколько повысить эффективность использования дисков. С другой стороны, планирование системы становится еще более творческим занятием. Предположим, что нам нужен пул из NL SAS дисков. Логично использовать RAID6 и, как следствие, мы вынуждены использовать 17 дисков (одна группа 14+2 и пригодится хотя бы 1 hot-spare диск). Если же нужно увеличить объем системы, то дисков нужно уже 33 (а лучше бы 34). И здесь мы сталкиваемся с тем, что уместить 34 диска в дисковые полки по 15 дисков довольно проблематично, а значит потребуется 3я полка, которую мы также не сможем заполнить. В любом случае, выбор “большой” RAID группы накладывает определенные ограничения на апгрейд системы (в плане стоимости такого апгрейда). Конечно, есть полки высокой емкости, но и там диски “ровно” не укладываются.
Такими изменениями производитель нам как бы сам намекает, что оставшееся место самое время заполнить дисками SSD, чтобы использовать все прелести FAST Cache или FAST VP. И здесь мы сталкиваемся с новым изменением – в пул можно будет включать RAID-группы разного типа, т.е. в пул с RAID6 из NL SAS дисков можно спокойно подключить RAID5 из SSD дисков (сейчас пользователь вынужден использовать только один тип RAID внутри пула, независимо от типа дисков).
Изменения коснулись и технологии FAST VP – в новом релизе данные будут сначала попадать на SSD, а уже потом перемещаться на более медленные диски. Такой подход имеет свои плюсы и минусы, но зато позволяет получить немедленный видимый эффект от использования SSD. И становится заметно проще демонстрировать преимущества от FAST VP заказчику – достаточно немного нагрузить систему. Фактически, технология FAST VP становится более похожей на FAST Cache (хотя отличия, несомненно, остаются).
В упомянутой выше статье было много сказано про недостатки пулов в VNX, связанные с расширением дискового пространства. Похоже, что и эту проблему в EMC не обошли своим вниманнием – помимо уже описанных новшеств, нас ждет еще и автоматическая ребалансировка внутри пула. При добавлении дисковых групп в общий пул, произойдет перераспределение данных по пулу. С одной стороны, это очень хорошо – добавили диски и увеличили производительность, а не только объем. С другой стороны, перераспределение занимает время и нагружает контроллеры. А как обычно происходит? Диски добавляем, когда уже и места нет, и производительность ниже необходимой. Планируйте своевременно апгрейды! (Это правило, кстати, относится не только к EMC, но и ко всем другим системам).
Ну и самое радикальное новшество – на пулах появятся новые снапшоты! Это действительно принципиальное изменение (и я понятия не имею, почему еще все производители, которые так рекламируют thin provisioning, не начали так делать). Появляются снапшоты, работающие по технологии redirect on write. Т.е. больше нам не нужно резервировать отдельное место под мгновенные снимки и системе не нужно копировать “старые” данные в этот резервный пул. В случае redirect on write новый блок данных (после создания снимка) просто записывается в новое место, а LUN “собирается” на основе указателей. Т.е. примерно так, как это реализовано в NetApp или в IBM XIV. А это дает существенные преимущества – до 256 снимков на том, нет потери производительности из-за использования снимков, возможность делать снапшоты снапшотов, доступность снапшотов на запись. Да, да - извечные противники в плане технологий стали еще ближе друг к другу! Если NetApp выступает своего рода первопроходцем, то EMC идет по намеченному курсу, делая нужные изменения (не факт что в нужный момент, но зато не приходится растрачиваться на рекламу новых фишек – публика уже “подогрета” рассказами NetApp).
Но гонка с NetApp на снапшотах не закончена и у VNX появляется еще один дополнительный программный продукт – AppSync. Он предназначен для защиты приложений (на старте - Exchange и VMware, потом планируются и другие). Пользователь задает уровень доступности (SLA) для конкретного приложения и может самостоятельно восстанавливать данные в случае сбоя.
Большинство из объявленных новшеств доступны только в системах VNX, а владельцам VNXe придется подождать – из-за особенностей реализации блочных протоколов в VNXe.
Посмотрим, что готовят конкуренты в ответ!
среда, 20 октября 2010 г.
IBM: еще один тяжеловес с SAS дисками
Возвращаюсь к уже сделанным анонсам – IBM, вслед за HDS, выпустили продолжение для своей линейки DS8000. Как и ожидалось, из DS8700 название системы превратилась в DS8800. Аппаратных новшеств в системе много – надо же чем-то крыть конкурентов. Впрочем, IBM традиционно сохраняет преемственность кода в своих “восьмитысячниках”, поэтому непосредственным изменениям программной части подверглось (как утверждается) не более 15% от общего объема.
Итак: процессоры из Power 6 4.7ГГц превратились в Power 6+ 5ГГц. Это пожалуй самое незначительное изменение в системе. Дальше – больше. Вместо 2Гбит дисковых адаптеров (device adapter, DA), появились 8Гбит карты. Аналогично и со стороны хостов – для DS8800 доступны 8Гбит хостовые FCP/FICON адаптеры. Отдельно стоит отметить что дисковые адаптеры остались Fibre Channel, хотя диски уже ставятся только SAS и только 2.5’’! Преобразование из FC в SAS делается внутри дисковой полки (которые теперь называются уже не Megapack, а Gigapack). Между дисковыми полками и контроллерами – оптика, что с одной стороны удобнее и лучше меди с точки зрения воздухотока, но гораздо легче ломается. По подключению дисковых полок есть довольно своеобразный вариант – для бюджетных решений (если вообще можно для таких систем говорить о бюджетных решениях) предлагается “business class cabling” - на каждый дисковый адаптер подключается больше полок, что снижает стоимость решения за счет снижения производительности бэкенда. В каждый Gigapack помещается не 16 дисков (как раньше), а 24 и занимает он только 2U:
До дисков “внутри” – SAS 2.0 6Gbps, наружу к дисковым адаптерам – FC 8Gbps. Блоки питания и вентиляторы стоят внутри каждого “гигапака”. Диски поддерживаются SAS 2.5’’ 10k, 15k и SSD (устанавливаются “паками” по 24 штуки). Максимально можно установить 1056 дисков, причем потребуется для этого только 3 шкафа (ранее на 1024 диска нужно было 5 шкафов). В максимальной набивке DS8800 потребляет менее 20kW.
Еще одно из важных изменений – теперь охлаждение реализовано стандартно – с фронта забираем холодный воздух, назад – горячий. Ранее горячий воздух выходил сверху, а забирался и спереди, и сзади, что создавало определенные сложности в проектировании.
С выпуском явно торопились – многие возможности из DS8700 перенести к анонсу не успели (скорее всего перенести-то успели, но вот оттестировать нормально – нет), поэтому если хочется использовать например Easy Tier, Remote Pair FlashCopy, Quick initialization и thin provisioning, 16 TB LUN, то нужно ждать первого квартала 2011 года. К этому моменту IBM обещает все сделать.
среда, 1 июля 2009 г.
HDS Dynamic Provisioning для AMS2000
Меня уже давно занимает вопрос, как нормально можно перевести термин "thin provisioning"? Вроде бы вполне понятно, что именно он означает, но найти нормальный русскоязычный эквивалент проблематично. Выделение дискового пространства по требованию? Звучит сравнительно понятно (хотя и не отражает всего смысла, так как неплохо бы добавить еще "небольшими блоками"), но вместо двух слов получили уже пять, а это уже, пожалуй, перебор. Более короткий вариант я лично придумать не могу, поэтому лучше буду использовать англоязычный вариант.
В HDS пошли другим путем и придумали свой собственный термин "Dynamic Provisioning". С 3го августа Dynamic Provisioning будет доступен для систем серии AMS2000. Какие возможности получает пользователь и как это работает?
Для начала, "как работает". Используя новые возможности, можно объединить несколько RAID-групп в один пул (HDP Pool) и уже из этого пула выделять луны (HDP Volume, Virtual LUN) для серверов. При этом, суммарный объем соозданных Virtual LUN может превышать доступный физически объем. По мере того как очередные блоки данных записываются на LUN, происходит динамическое расширение Virtual LUN. Пространство для Virtual LUN выделяется из HDP Pool блоками (chunk) по 1ГБ (поэтому "thin" это конечно довольно громко сказано). Система осуществляет распределение этих блоков между RAID-группами, входящими в HDP Pool: сначала выделяется chunk размером 1ГБ на первой RAID-групппе (для каждого из Virtual LUN), а когда он будет полностью заполнен, выделяется 1ГБ chunk на второй RAID-группе и т.д. Каждый chunk состоит из 32х страниц по 32МБ, но в данном случае это скорее логическое разделение, так как выделяется все равно пространство минимум в 1ГБ.
Что декларируется? Конечно же, прежде всего, эффективное использование дискового пространства! Разумеется, это большой плюс (особенно когда нет четкого представления, какова динамика роста требований к объему). За счет динамического выделения дискового пространства можно избежать довольно неприятных ситуаций с тем, что нужно создать новый том, а места уже нет, хотя имеющееся дисковое пространство используется неэффективно. Мониторинг используемых ресурсов позволяет заранее спланировать приобретение дополнительных дисков. Кроме того, обещается рост производительности системы за распределения Virtual LUN по многим RAID-группам в рамках HDP Pool (а кто же откажется от такого плюса?).
А есть ли минусы? Ну как же без них! Во-первых, (как я понял) для Virtual LUN можно использовать только ShadowImage, а TrueCopy и Snapshot на текущий момент не работают. Во-вторых, несмотря на то, что заявляется об увеличении производительности за счет распределения Virtual LUN по нескольким RAID-группам, эффект от такого распределения будет очень сильно зависеть от локализации запросов к LUN - так как распределение делается блоками по 1ГБ (если запросы идут к участку данных объемом менее 1ГБ, мы с высокой вероятность будем использовать только одну RAID-группу и уж точно не более двух). Да, мы имеем возможность распределить много LUNов по многим RAID-группам (и это может дать положительный эффект), но вот если, по стечению обстоятельств, запросы будут приходиться на одну RAID-группу, то эффект может быть сильно отрицательный (а вероятность получить именно такую ситуацию при 1ГБ блоке, как минимум, не нулевая). В-третьих, если для систем USP/USP-V есть возможность исключить "пустые" блоки (zero page reclaim), то для AMS2000 такой возможности нет. Помимо перечисленного нужно помнить, что Dymanic Provisioning эффективен не для всех файловых систем (например, для ext2/ext3 эффективность будет сравнительно небольшой, а для UFS использовать HDP вообще нет смысла).
Итог обычен - выбирая решение, нужно не только слушать дифирамбы продавца, но и помнить про технические особенности, а также про то, для чего именно Вам нужен тот или иной продукт.
