`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Полнотекстовый поиск – новый «пожиратель ресурсов» в бизнес-приложениях

С переходом бизнес-приложений на Web-доступ меняются требования к «железу»: для ряда задач многоядерность становится предпочтительнее высокой частоты.

При обращении к приложениям и данным через браузер скорость выполнения операций на сервере перестает быть критичным местом: SQL-запрос на сервере отработается в сотни и тысячи раз быстрее, чем происходит передача данных и отрисовка пользовательского интерфейса на конечном устройстве. Бессмысленно наращивать производительность самого сервера, когда задержки на SQL-сервере составляют всего 1-2% от задержек доставки данных пользователю через Internet. Бороться за следующие 1-2%? Когда пользователей много, а задержки по сети для каждого различны и слабо предсказуемы (типичная ситуация для мобильных сотрудников), узким местом становятся каналы доступа.
Зато переход на Web-доступ актуализировал две новые задачи, малозначимые в закрытой корпоративной среде с отстроенными под бизнес-задачи параметрами.

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

Вторую задачу породили растущие требования бизнес-приложений. Необходимость работать с огромными товарными справочниками -  в десятки-сотни тысяч и даже миллионы наименований - делает чрезвычайно трудоемкой работу с полями классификации товаров. Любой продавец автомобильных шин (со складом 10 комплектов колес) предложит вам номенклатуру почти всех мировых брендов всех типоразмеров «под заказ». Да, на складе нет, но в справочнике товаров есть! (Складские остатки поставщиков должны быть видны в своей программе). Что уж говорить про поставщиков автозапчастей? А про условную "Розетку"?

Мы приходим к классической задаче в Internet – полнотекстовому поиску с логическими операторами, весьма ресурсоёмкой. Кроме быстрого доступа на чтение к данным (по сути, кеширования части данных в RAM сервера), необходимо отрабатывать большое количество одновременных запросов пользователей. Не правда ли, напоминает отголоски давней битвы поисковых систем – между Altavista, использующей самые быстродействующие CPU своего времени 64-битные DEC Alpha, и Google, сделавшей ставку на типовые и недорогие 32-битные Intel Pentium?

Полнотекстовый поиск – новый «пожиратель ресурсов» в бизнес-приложениях

Производители процессоров тенденции отслеживают. Intel предлагает до 28 ядер в одном Xeon,  AMD – целых 32 ядра в процессоре EPYC. Даже физика на их стороне: с ростом частоты тепловыделение растет квадратично, а с увеличением ядер – линейно.
Чем больше будет корпоративных бизнес-приложений с Web доступом, тем больше будет спрос на ядра в одном процессоре.

Web-интерфейс – стандарт доступа к корпоративным данным

Современные бизнес-приложения для предприятий любого масштаба либо уже имеют Web-интерфейс, либо в ближайшее время обзаведутся как опцией. Либо вымрут.

Web-сервисы с «быстрым стартом» и продуманным пользовательским интерфейсом отбирают  аудиторию у классических приложений, требующих инсталляции на устройство. Поначалу это были всевозможные CRM и системы поддержки продаж (SalesForce - яркий пример), управление проектами (Asana), потом подтянулись остальные. Есть даже полноценные системы управления производством (Frepple), доступные через Web.

Web-интерфейс – стандарт доступа к корпоративным данным

(Картинки кликабельны)

Естественно, гранды бизнес-ПО не могли игнорировать такой тренд. Microsoft Dynamics CRM 2011 уже имела Web-доступ. Browser Access function появился в SAP Business One 9.2. По состоянию на сегодня в 1С:Предприятие 8 наиболее популярные конфигурации - «Бухгалтерский Учет», «Управление Небольшой Фирмой», «Управление торговлей», «Документооборот»,  «CRM» - могут работать и локально как приложение в «толстом» клиенте, и в режиме Web Access либо через браузер, либо посредством «Тонкого клиента». CRM-ERP система Odoo изначально является Web-приложением, запускаемым как локально, так и в формате Web-сервис. Причем Odoo в некоторых моментах даже перешла на следующую стадию: модуль «Точка продаж» (по сути, рабочее место кассира или продавца в рознице) запускается в браузере, может работать автономно на устройстве, и затем синхронизироваться с основной системой.

Web-интерфейс – стандарт доступа к корпоративным данным

Web-приложение чрезвычайно удобно и выгодно как конечному пользователю, так и компании. Доступ обеспечивается с практически любого устройства, имеющего Web-браузер и комфортный для работы экран. Нет необходимости что-либо покупать или устанавливать – достаточно собственного телефона, планшета или ноутбука, и подписки на сервис с ежемесячной оплатой. Не нужно покупать  дорогостоящее ПО и оборудование, обеспечивать их поддержку. Обучение – предельно просто, есть документация и видео-инструкции. Протокол https обеспечивает и безопасность, и беспрепятственное прохождение практически всех брандмауэров.

Web-интерфейс – стандарт доступа к корпоративным данным

Как следствие, сумма начальных инвестиций для старта любого проекта, использующего Web-доступ к бизнес-приложениям, резко снизилась. Стоимость поддержки, за счет отказа от обслуживания клиентских устройств – также снизилась. А скорость запуска и удобство использования – возросли.

Там, где есть задачи подключения множества сотрудников, с различных мест, с разнотипных по формату устройств  – разумной альтернативы Web-доступу и адаптивному дизайну уже просто нет.

Не ставьте бытовые SSD в серверы!

Тема пагубности использования не-серверных серий SSD в серверах отнюдь не нова. Об этом многократно говорилось на семинарах Intel и других производителей дисков SSD. Часто это происходит как результат веры в маркетинговые лозунги. На последнем графике наглядно видно, что производительность бытовых SSD в режиме записи под серверной нагрузкой вполне сопоставима с бытовыми же HDD. А потом возникают легенды о том, что «SSD ничего не дает».

Данный материал - это краткий пересказ публикации Dan Lovinger на Microsoft Technet:  Don’t do it: consumer-grade solid-state drives (SSD) in Storage Spaces Direct

Логика SSD
SSDустройство, состоящее из набора микросхем флэш-памяти NAND, подключенных к внутреннему контроллеру FTL (flash translation layer). Производительность и долгий срок службы SSD зависят от реализации контроллера и его набора процедур в буферной памяти (DRAM) с использованием резерва ячеек NAND (overprovisioning, spare):  cбора мусора, освобождения страниц памяти под новую запись, выравнивания износа ячеек, фоновых проверок целостности данных.

Не ставьте бытовые SSD в серверы! 

Для защиты данных есть два механизма FTL: коррекция ошибок (ECC) и замещение ячеек, выработавших свой ресурс, ячейками из резерва. Когда их запас заканчивается, SSD приходит конец.

Буферная память работает во всех операциях SSD, связанных с размещением данных. Она энергозависима. В потребительских SSD защиты DRAM по питанию нет. В серверных SSD корректное завершение транзакций записи при обесточивании обеспечивают суперконденсаторы.

По сути, два определяющих отличия серверных SSD от бытовых:

    Наличие энергонезависимого кэша записи (Power loss protection)

    Большой ресурс перезаписи ячеек (3-10 DWPD против 0.1-0.2  DWPD)

 

Эксперимент с потребительскими SSD

Спецификация типичного SATA SSD потребительского класса емкостью 1 TB выглядит многообещающе:

    QD32 4K Read: 95,000 IOPS

    QD32 4K Write: 90,000 IOPS

    Endurance: 185TB при пятилетней эксплуатации.

QD (“queue depth”) – количество отдельных запросов ввода-вывода к устройству во время теста. Расхожее значение 32 объясняется ограничением на число команд, обрабатываемых SATA-устройством. У SAS, а тем более NVMe, предел намного выше.

Переводя показатели endurance в более привычную метрику device-writes-per-day (DWPD), получим ресурс перезаписи

185 TB / (365 days x 5 years = 1825 days) = ~ 100 GB в день, что составляет:

100 GB / 1 TB total capacity = 0.10 DWPD

Для начала тестовый файл размером 100 GB был последовательно записан на SSD несколько раз. Использовалась утилита DISKSPD 2.0.18 с установками QD8 70:30 4 KB, смешанной нагрузкой чтения/записи в 8 потоков. Буфер записи активирован:

diskspd.exe -t8 -b4k -r4k -o1 -w30 -Su -D -L -d1800 -Rxml Z:\load.bin

Не ставьте бытовые SSD в серверы! 

Тест длился 30 минут. Падение производительности на ~ 10K IOPS примерно через две минуты - это нормально: у FTL закончился запас чистых страниц NAND под новые записи. По исчерпанию резерва SSD работает медленнее, в паузах контроллер предпринимает действия для восстановления производительности: убирает мусор, освобождает страницы. В типичных пользовательских сценариях - как загрузка веб-страниц - разницы никто и не заметит.

 

Тот же тест, но со сквозной записью, write-through (-Suw):

diskspd.exe -t8 -b4k -r4k -o1 -w30 -Suw -D -L -d1800 -Rxml Z:\load.bin

Режим write-through показывает истинные задержки NAND, обычно маскируемые FTL/буфером.

Не ставьте бытовые SSD в серверы!


Ой!

Это больше  не “SSD”: через пять минут работы производительность записи упала до уровня HDD, около 220 IOPS. FTL, лишенный буфера, записывает данные в ячейки, разруливает потоки чтения и записи, выполняет фоновую активность – но крайне медленно. Про “кэширование” на таких SSD можно забыть. Жить его ячейки будут недолго.

О важности энергонезависимого буфера.
Все серверные SSD имеют энергонезависимый буфер – это один из признаков этих устройств. С ним SSD гарантирует ОС и приложениям корректное завершение операций записи после попадании данных в буфер даже в случае исчезновения энергоснабжения. Как правило, он реализуется за счет установки на SSD блока суперконденсаторов (на картинке ниже маленькие желтенькие).

Не ставьте бытовые SSD в серверы!

Наличие энергонезависимого буфера обеспечивает предсказуемо высокую и стабильную производительность (как на первом графике), и ресурс ячеек вырабатывается равномерно. Все это обеспечивается серверным

SSD под смешанной интенсивной нагрузкой. 

В финале…
Покупатели должны иметь возможность выбрать SSD, соответствующее задачам сервера. Да, они будут дороже, чем устройства потребительского класса. Но, надеюсь, мы убедили вас, почему серверные SSD того стоят.
Будьте в безопасности!

 

Есть ли альтернативы M.E.Doc?

M.E.Doc оказался одной из основных  жертв атаки вируса Petya. Как наиболее распространенный пакет,  M.E.Doc будет и в дальнейшем находиться в зоне повышенного риска.

По сути M.E.Doc является наследником системы  «БЕСТ-Звіт», и родоначальником налоговой отчетности в электронном виде. И остается самым распространённым  ПО сдачи регламентированной отчетности, инсталлируемым локально.

Кроме системы документооборота и сдачи регламентированной отчетности M.E.Doc,  «Интеллект сервис» является поставщиком еще целого ряда продуктов : on-line система документооборота и сдачи регламентированной отёчности «СОТА», ERP-подобная система IS-Pro, сети магазинов электронных услуг «Твій час»  (на этой страничке внизу приведен более полный список продуктов), и т.д.

Есть ли альтернативы M.E.Doc?

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

Полный список ПО электронной отчётности можно найти по ссылке «Перелік програмного забезпечення, за допомогою якого можливо здійснювати електронне звітування». По личному впечатлению автора, наиболее распространенными  из альтернативных пакетов электронного документооборота и сдачи регламентированной отчетности, допускающих локальную установку – это «Соната»,  «Арт-Звіт» и «1С:Звіт».

Исходя из отзывов пользователей «Сонаты» и «Арт-Звіт Про», с которыми знаком автор, данные продукты по своим функциональным возможностям близки к M.E.Doc. При этом имеют более интересную ценовую политику (если не брать в расчет акции). И существенно более внимательны к запросам конечных пользователей. «Арт-Звіт», к примеру, имеет интеграцию с системой «Нова Бухгалтерiя». А «Соната» предлагает легкий переход с целого ряда других систем.

Есть ли альтернативы M.E.Doc?

Баннер на сайте гласит, что «1С:Звіт» является совместной разработкой 1С и M.E.Doc.
Есть ли альтернативы M.E.Doc?
Важно, что «1С:Звіт» доступен без дополнительной оплаты для подписчиков «1С:ІТС ПРОФ».
С точки зрения пользователей 1С – это наиболее удобный продукт, работающий как с 1С:Предприятие 8, так и с более старой версией 1С:Предприятие 7.7.

Есть ли альтернативы M.E.Doc?

Так что выбор, к счастью для пользователей, есть.
И вполне достойный.
Слава конкуренции!

1С – Все будет хорошо!

Вадим Мазур 16 мая однозначно заявил: «…Мы будем продолжать поддерживать наших клиентов и предоставлять им обновления. Мы найдем пути для этого».

Так что повода для паники у текущих украинских пользователей систем на основе 1С:Предприятие 8 – нет.
Продукты компании 1С являются важной частью IT-ландшафта Украины, и прекратить их использование и поддержку в бизнес-среде по принципу «Поезд, стой, раз, два!» просто невозможно.

1С – все будет хорошо

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

1. В связи с блокированием счетов правообладателя на территории Украины в течении некоторого времени не будет возможности приобрести новые лицензии на платформу 1С:Предприятие 8  – пользовательские лицензии, серверные лицензии, апгрейды и т.д. (что напрямую связано именно с платформой).
Технически ситуация может быть решена путем выдачи прав на территории Украины другому юридическому лицу, т.к. сами продукты 1С не находятся в секционном списке. 99,99% пользователей 1С:Предеприятие все равно, как именно называется организация-правообладатель – их интересует законная возможность приобрести лицензии. Регистрация нового юридического лица – это не долго. Думаю, решение уже принято и находится в стадии реализации, так что ждать не долго.

2. Может возникнуть необходимость дополнительного юридического оформления поддержки пользователей согласно договоров «Информационно-Технического сопровождения» (ИТС) – к примеру, придётся переоформить Договор или подписать дополнить Доп. соглашение. Что не должно сказаться на техническом аспекте выпуска обновлений и доступа к обновлениям (т.к. требования к провайдерам блокировки ресурсов, связанных с 1С, нет). Это вполне может быт организовано как плавный и спокойный процесс.

3. Развитие и исправление ошибок в украинских Конфигурациях. Здесь, опять-таки, технически проблем быть не должно. Украинские конфигурации разрабатываются в Украине, украинскими разработчиками. Даже если юридическое лица, официально разрабатывавшие данные конфигурации попали под санкции – всегда есть возможность всем коллективом перейти на работу в другое юридическое лицо. Буквально за 1-2 дня. Продукты, еще раз подчеркну – не находятся в секционном списке.

Это «запрограммированный» решением РНБО сценарий развития событий. Ведь не зря же сам продукт 1С:Предприятие 8 и его производные не включены в секционный список.
И судя по первым заявлениям "Скайлайн Софтвер", команда к нему давно готова.
Конечно, возможен и конфронтационный вариант. Когда правообладатель заявит, что он «умывает руки» и все вопросы к РНБО. Когда разработчики конфигураций заявят об увольнении сотрудников и прекращении разработок. Лучшие кадры начнут массово уходить с рынка, и начнется экстренный поиск других систем конечными пользователями.
Но это будет уже не бизнес-решение.
И, с моей точки зрения, такой сценарий крайне маловероятен.
Давайте подождем.
Все буде добре.

Есть ли альтернативы 1С на украинском рынке

В связи с публикацией подписанного Президентом решения РНБО, в котором упоминается в т.ч. компания 1С, произошел целый шторм:
 « - А что использовать дальше?».

Вначале – легкое успокоительное.
У текущих владельцев 1С – на мой взгляд, все будет хорошо.
Санкции ввели на определённые компании, а не на продукт. Законные владельцы лицензий могут без ограничений использовать ранее приобретенное ПО.
Поддержку пользователей можно легко обеспечить, зарегистрировав полностью украинскую компанию, и начав выпускать обновления от нее.
Будет ли это сделано – зависит уже от решения самой 1С и ее истинной заботе о своих потребителях.
Даже если не будет – сообщество специалистов 1С в Украине достаточно обширно, что бы решить этот вопрос своими силам.
С продажей лицензий, наверное, будет чуть сложнее. Но мне почему-то кажется, что решение будет найдено.

Потому как смысл санкций не столько в запрещении, сколько – в переориентации на другие решения и другие рынки.

К примеру,  есть целый набор продуктов от украинского поставщика:
M.E.DOC – вполне себе известная программка, в особых представлениях не нуждается, активно развивается.
COTA – Web-сервис, предоставляющий услуги учета, сдачи отчетности и документооборота.
ІС-ПРО – Система управления предприятием с довольно обширными функциональными возможностями.
Есть и другие решения от украинских компаний.

А еще можно посмотреть очень симпатичный продукт Odoo. Имеющийся в платной версии Enterprise и бесплатной Community Edition. Ранее известный как OpenERP.
Это модульная ERP-подобная система, с довольно приличной CRM с возможностью подключения к SIP-телефони, мощный модуль продаж с Canban, готовый Интернет-магазин с «партнеркой», и многое-многое другое.

Есть ли альтернативы 1С на украинском рынке

Из недостатков – отсутствие полноценного украинского бухгалтерского учета.  Пока…
Развивает ее, помимо владельца в виде компании из Бельгии Odoo SA, еще и довольно большое международное сообщество.
Она может быть развернута локально, или получена как Web-сервис.
В ней используется открытый код на Python.
Имеет хождение в Европе и Северной Америке.
Чем не вариант?

P.S.: Список различных решений по ведению учета и сдаче отчетности, разной сложности, найденных простым поиском:
IT-Enterprise, TAXER, iFin, Деловод, Смарт-Бухгалтерия, Соната, Облік SaaS.
Он наверняка не полон.
Сам не проверял.

SAS HDD vs Enterprise SSD - какой диск теоретически надежнее

При проектировании серверов вместо SSD все еще встречается использование SAS HDD в качестве дисков под ОС или дисков для хранения данных, аргументируя это более высокой надежностью устройств SAS HDD относительно дисков SSD, в т.ч. и Enterprise класса.

Так ли это на самом деле?

Давайте обратимся для начала к теории.

Наиболее часто в качестве теоретической надежности дисков используется параметр “Non-recoverable Read Errors per Bits Read”, что можно перевести как  “Вероятность появления невосстановимой ошибки чтения на количество считанных бит”. Он показывает, после чтения какого объема данных с диска согласно статистике следует ожидать появления невосстановимой ошибки.

Для сравнения возьмем диски:

1. Обычный настольный SATA Desktop HDD 7200 prm Seagate Barracuda ST4000DM.

2. Так называемыеCapacity-Optimised Enterpriseдиск HDD 7200 prm, которые бывают с интерфейсами SATA (SATA Raid Edition) и SAS (NL SAS)  Seagate Constellation ES.3 ST3000NM.

3. Классический серверный SAS HDD Enterprise-класса 15 000 prmSeagate ST600MP.

4. SAS SSD Enterprise-класса того же производителя, и с интерфейсом SAS SeagateST400FM .

5. И в качестве альтернативы SATA SSD младшую линейку Enterprise-класса SSD s3500 series от компании IntelIntel SSD DC s3510.

Утоним только, что Intel использует несколько иной параметр, UBER Uncorrectable Bit Errors Rate” (стр. 14, раздел 2.6). О его отличии в т.ч. написано в документации от Intel к SSD. Для нас же важно, что он дает результат «не хуже», чем классический “Non-recoverable Read Errors per Bits Read”.

Второй популярный параметр показывает вероятность отказа диска – AFR (annual failure rate - годовая интенсивность отказов).
Без учета тонкостей, ее можно выразить через другой параметр,
MTBF:

AFR = (power-on hours / MBTF) * 100%

Power-on hours (время работы в часах) для постоянно включенных серверов составляет приблизительно 8760 часов.

Таким образом, для MBTF = 2 000 000 часов получаем приблизительно AFR = 0.44%.

Т.к. для сервера важен AFR, данные документации по дискам, где указан MBTF,  пересчитаем в AFR

Далее составляем табличку:

SAS HDD vs SSD - какой диск надежнее теоретически

Прекрасно видно, что по вероятности появления невосстановимой ошибки  Enterprise SSD как с интерфейсом SAS, так и с интерфейсом SATA на порядок превосходят классические SAS HDD.

По показателю годовой интенсивности отказов показатели Enterprise SATA SSD равны таковым у SAS HDD, а у Enterprise  SAS SSD – существенно лучше.

Это при сопоставимых емкостях и при вполне сравнимых ценах.

Что же касается практики, то наиболее корректным будет привести ссылки на опыт эксплуатации SSD тех компаний, у которых их тысячи и многолетний опыт.

Тут хорошим примером может быть отчет  FacebookA Large-Scale Study of Flash Memory Failures in the Field о результатах эксплуатации SSD в течении 4-х с лишним лет. В нем есть реальные данные по UBER (Table 1), существенно отличающиеся от теоретических. Есть и failure rate (Figure 2), удивительно совпадающие с теорией.

Ну а для любителей проникнуть в детали эксплуатации SSDв сверхжестких условиях – отчет с данными за 6 лет и очень глубоким погружением в тему от Google Flash Reliability in Production: The Expected and the Unexpected ” (pages 67-80).

С высокой долей вероятности, нагрузка на диск обычного сервера будет заметно меньше, чем достается SSD у Facebook и Google.

Выводы:
- Исходя из данных о теоретической надежности
SSD дисков Enterprise-класса, они ни в чем не уступают, а зачастую и превосходят «классические» SAS HDD;
 - Практические результаты эксплуатации
SSD подтверждают высокую надежность данных устройств;
 - Использование
SAS HDD в качестве системного диска либо основного диска хранения данных с технической точки зрения является скорее атавизмом и «данью привычке», а то и желанием поставщика распродать залежавшийся товар.

SAS SSD vs SATA SSD - Производительность протоколов

При массовом распространении SATA SSD серверного класса (пример - интеловская серия S3700 многие задаются вопросом: а нужны ли в сервере SAS? Если речь о 2-4 SSD, скорее всего, протокол SAS действительно лишний.

Кому нужны низкие задержки доступа к данным, выберут NVMe SSD (снижение латентности почти в три раза). Правда, их не объединить в аппаратный RAID.

Но когда нужны минимальные задержки и объединение в аппаратный RAID нескольких устройств – альтернативы протоколу SAS просто нет.

Давайте посчитаем.

SATA – это всегда 6Gb. SAS бывает 6Gb и 12Gb. Грубо, предельная теоретическая пропускная способность интерфейса SATA 6Gb на коротком блоке в 4К равна 150 KIOPS (600 MB/s поделить на 4KB). Это без учета накладных расходов самого протокола. Интерфейс SATA полудуплексный (half-duplex), в отличие от полнодуплексного (full-duplex) SAS. Для SATA эти 150 KIOPS – полная скорость в обоих направлениях, в то время как для SAS 6Gb потенциально возможны 300 KIOPS для операций чтения и записи одновременно (что было не важно для HDD, но может стать актуальным для SSD). Для SAS 12Gb на тех же блоках 4KB мы получим удвоение потенциала пропускной способности - до 300 KIOPS в одном направлении или до 600 KIOPS в смешанном режиме чтения/записи.

SAS SSD vs SATA SSD - Производительность протоколов.

Дадим шанс SATA – останемся в рамках стандарта 6Gb. Если разделить 6Gb/s на 150 KIOPS, то получим теоретические 6,67 микросекунды на одну транзакцию по передаче блока 4KB. На самом деле это совпадает с реальной длительностью такой транзакции, которая близка к 6,83 микросекунды.

Сам протокол SATA при передаче каждого пакета тратит порядка 760 наносекунд на установку регистров (12*8bits*10/8) и обработку прерываний на стороне хоста. В результате получаем теоретическую пропускную способность на уровне 572 MB/s. Лучшие из SATA устройств вытягивают скорость передачи до 550 MB/s. Это примерно соответствует пределу в 132 KIOPS.

На практике, интерфейс SAS 6Gb обеспечивает в среднем на 52% выше эффективность относительно SATA 6Gb даже в условиях использования всего одного своего двунаправленного порта (У SAS их два, но это востребовано в двухконтроллерных системах хранения с двойными экспандерами – где достигается удвоение пропускной способности).

SATA работает в режиме «устройство-хост», обособлено с каждым устройством. SAS по своей логической структуре – это сеть. Т.е. SAS умеет мультиплицированно работать с множеством устройств, имея расширенное адресное пространство и не тратя времени каждой раз на формирование канала заново.

SAS SSD vs SATA SSD - Производительность протоколов.

Как известно всем, кто хоть раз запускал тесты – максимальной производительности дисковое устройство достигает только тогда, когда идут не одиночные запросы, а выстояна очередь. На длине очереди 1 и 32 – будут кардинально различные результаты даже у SATA SSD. Длина очереди команд, поддерживаемых устройством SATA – 32 команды. А SAS – 256 и более команд. Важность этого параметра подчеркивает новейший стандарт NVMe, который устанавливает стартовую планку в 32000 команд.

Итого:

  1. Потолок производительности SAS 6Gb при интенсивной нагрузке вполовину выше потолка SATA 6Gb - только за счет полнодуплексной передачи и особенностей протокола. Накладные расходы у SAS всегда ниже;
  2. Переход к SAS 12Gb увеличивает отрыв;
  3. SAS работает с множеством устройств как единой сетью;
  4. Длина очереди SATA всего 32 команды, а SAS – от 256;
  5. В отказоустойчивых SASJBOD работа с каждым устройством SAS может вестись по двум полнодуплексным каналам (еще одно удвоение пропускной способности).

Практические рекомендации можно свести к простому правилу:

  • Если у вас 2-4 диска, то вполне можно ограничиться SATA;
  • Для четырех и более дисков (с учетом перспективы расширения) предпочтительнее SAS.

SAS vs SATA в отказоустойчивых решениях на Microsoft Storage Space

В процессе обсуждения дисков для построения отказоустойчивого хранилища на основе технологии Microsoft Storage Space часто поднимаются вопрос: почему нельзя установить SATA SSD вместо более дорогих SAS SSD в SAS JBOD.

Здесь ключевое слово – «отказоустойчивое».
SAS – это сеть, обеспечивающая минимум 2 пути к конечному устройству хранения – SSD или HDD.

Без резервирования каналов связи внутри SAS JBOD вероятной точкой отказа вполне может стать единственный путь к диску.

Потому, если речь идет о отказоустойчивой инфраструктуре,  использовании томов CSV (Cluster Shared Volume) и построении кластера – то используются исключительно устройства с интерфейсом SAS.

В то же время в SAS JBOD вполне может быть уставлены устройства с интерфейсом SATA. Которые технологически будут доступны в Storage Space, но не  узлам кластера, а какому-то одному узлу, в кластер не входящему (если таковой есть в сети SAS SAN).

Та же ситуация и с USB носителями, которые как и SATA, можно добавить в Storage Pool, можно собрать Storage Space, но нельзя на их основе создать том Cluster Shared Volume.

Только устройства SAS пройдут валидацию в дисковом пуле, создаваемом на узле кластера.

Более детально про SAS SAN можно посмотреть в материале «Коммутируемый SAS. Часть 2. Возможности».

И в конце – картинка, которая наглядно демонстрирует разницу SAS и SATA.

Сравнивая SAS и SATA, забывают, что кроме потенциальной отказоустойчивости – за счет двухпортового подключения – у SAS есть огромное преимущество в производительности.

SAS vs SATA в отказоустойчивых решениях на Microsoft Storage Space

RAID Rebuild, Auto-Rebuild – краткие практические рекомендации

В случае выхода из строя даже 1-го из дисков в RAID-массиве крайне соблазнительным выглядит воспользоваться HotSpare диском, либо же заменить вышедший из строя диск на аналогичный, и насладиться функцией Auto-Rebuild (если таковая есть у RAID-контроллера), или же запустить Rebuild вручную.

Если вам дороги ваши данные – абсолютно неверный путь!

Почему – поясню на примере.

Массив, RAID 6, из порядка 16 HDD, уже пару лет поработавший.

Понятно, что все диски в нем в более-менее одинаковом состоянии.

Выходит из строя 2 диска.

Пока – ничего страшного.

А при запуске процедуры Rebuild – выходит из строя еще 3 диска.

И это – как раз нормальная, типичная ситуация.

Исходя из практики, при выходе из строя диска в массиве, наличии HotSpare-диска и включенной опции Auto-Rebuild можно с вероятностью порядка 20-50% прогнозировать потерю данных, хранившихся на массиве.

Каков правильный путь в случае выхода из строя даже 1-го диска в массиве?

1. Останавливаем всякую работу с наиболее ценными данными. По возможности – со всем массивом. Задача – исключить или минимизировать запись.

2. Делаем Backup вначале наиболее ценных данных, затем всех остальных. Backup всех ценных данных разворачиваем и проверяем, что он «не битый», данные действительно корректны. Если удалось сделать полный backup, все данные развернуты на тестовой площадке и корректны – считаем, что крупно повезло.

3.1. Идеально – вынимаем аккуратно каждый диск и делаем его копию на аналогичный. Дале работаем с копией. Если находящаяся на дисках информация ценна, и не удалось сделать ее полноценны Backup – это единственно правильный путь. Не удалось самостоятельно восстановить данные на копии массива – обращаемся в специализированные компании, передавая им оригиналы дисков из массива.

3.2. Если сильно спешим, готовы рискнуть, полного комплекта дисков на замену нет, и успешно выполнился Backup (и проверена целостность данных) – вставляем диск «на замену» и запускаем Rebuild. Если больше ни одни диск не «отвалится» (а мы помним, что диски находятся в плюс-минус одинаковой степени износа) – за относительно короткое время массив будет восстановлен.

4. Если массив удалось восстановить процедурой Rebuild – радуемся, работаем дальше и наблюдаем по SMART за состоянием дисков.

5. Если массив восстановить не удалось – то либо создаем новый и восстанавливаем информацию из backup, либо ждем результатов от специализирующееся на восстановлении данных компании.

Оптимально воздержаться от использования функцией Auto-Rebuild в RAID-массивах, т.к. это крайне небезопасно.
К
примеру, в Microsoft Storage Spaces функции Auto-Rebuild нет.

 

P.S.: Спасибо коллегам, что обратили внимание.
Описанный подход применим к одиночным дисковым массивам,
и не применим к отказоустойчивым дисковым массивам с нулевым окном обслуживания в S
LA.

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT