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

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

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

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

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

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

Баннер на сайте гласит, что «1С:Звіт» является совместной разработкой 1С и M.E.Doc.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При проектировании серверов вместо 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 prm – Seagate ST600MP.

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

5. И в качестве альтернативы SATA SSD младшую линейку Enterprise-класса SSD s3500 series от компании Intel – Intel 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

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

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

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

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

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

Тут хорошим примером может быть отчет  Facebook “ A 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 в качестве системного диска либо основного диска хранения данных с технической точки зрения является скорее атавизмом и «данью привычке», а то и желанием поставщика распродать залежавшийся товар.

При массовом распространении 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 в смешанном режиме чтения/записи.

Дадим шанс 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 умеет мультиплицированно работать с множеством устройств, имея расширенное адресное пространство и не тратя времени каждой раз на формирование канала заново.

Как известно всем, кто хоть раз запускал тесты – максимальной производительности дисковое устройство достигает только тогда, когда идут не одиночные запросы, а выстояна очередь. На длине очереди 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.

В процессе обсуждения дисков для построения отказоустойчивого хранилища на основе технологии 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 есть огромное преимущество в производительности.

В случае выхода из строя даже 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.: Спасибо коллегам, что обратили внимание.
Описанный подход применим к одиночным дисковым массивам,
и не применим к отказоустойчивым дисковым массивам с нулевым окном обслуживания в SLA.

За десятилетия эры PC многие привыкли, что ПК – это некий «ящик», для которого необходимо выделить немного места. И раз в пару лет желательно разобрать и пропылесосить.

Первым в массовом потребительском сегменте эту парадигму поломал iMac mini в 2010 году, заменив «ящичек» маленькой и вполне симпатичной «коробочкой». Похоже, что в 2015 данный форм-фактор станет массовым и для систем под Windows.

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

Компактный Intel NUC – фактически готовый офисный ПК. С вполне приличной производительностью – процессор от экономичного Atom до Core i5.

В процессе локальной сборки в баребон добавляется только жёсткие диски (и это вполне может быть Intel SSD),  mini-PCIe модуль Wi-Fi (если нужен) и оперативную память SoDIMM до 8GB или до 16GB (о чудо, первый элемент не от Intel).

Есть и модель с поддержкой V-Pro,  что делает Intel NUC интересными в больших компаниях с единой панелью управления/обновления.

В том же направлении активно движутся и традиционные поставщики ПК – как пример HP с моделями Pavilion Mini и Stream Mini ($180).

Intel NUC – это не уникальная новая технология. Давно есть компактные ПК, точно так же крепящиеся на монитор. Есть даже «ПК из розетки».  Симптоматичным есть объем усилий, которые прикладывает Intel и другие игроки с целью замещения поставок ПК в традиционных форм-факторах на более компактные решения (там, где по той или иной причине не оптимальны систем All-in-One).

Вполне вероятно, что парадигма компактного полнофункционального ПК станет мейнстримом в бизнес-сегменте.

Спрос на on-line сервисы в Украине проходит очередной «круг опыта».

Вспомним недавнюю историю.

Примерно в 2006-м начался массовый перенос серверов в дата-центры, а то и отказ от собственных мощностей в пользу арендуемых. Бизнес, тогда еще не стесненный в средствах, покупал новые офисы на волне роста. Соразмерное развитие ИТ-служб требовало не просто замены старых серверов на новые, а застройки инфраструктуры с нуля: оборудования серверных комнат, поиска свободных электрических мощностей, бодания с разрешительной системой. При окупаемости капитальных вложений на уровне 5-8 лет, многие компании предпочли уйти в готовые дата-центры. Кризис 2008 года показал их правоту: рынки сдулись, деньги подорожали, собственные площадки тех, кто строил «на вырост», бездействовали, тогда как услуги провайдеров остались на прежнем ценовом уровне.

С 2010-го пошли “семейные” разборки. От греха подальше, компании повезли свой ИТ-скарб на Запад - создавая там дата-центры, или арендуя мощности с каналами связи, напрямую, или через операторов украинских площадок. Средства серверной виртуализации, в первую очередь от Microsoft, делали процесс переезда недорогим и относительно безболезненным. Смириться с нестабильным качеством каналов связи и задержками передачи данных было проще, чем работать в режиме ожидания незваных гостей. Спустя время, часть сервисов, критичных к задержкам (вроде «удаленных рабочих столов») все-таки вернулась в локальные дата-центры.

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

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

Все идет к тому что владельцы локальных дата-центров могут рассчитывать на некоторое оживление спроса на их услуги. Готовьте сани.

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

При чтении данных кэширование  даёт однозначный прирост производительности системы.

При записи данных получить повышение производительности за счет  кэширования  можно только ценой снижения надёжности.

Существуют две основные политики записи — «сквозная запись» (write-through) и «отложенная запись» (write-back).

При «сквозной записи» данные записываются непосредственно на основной носитель, и только потом дублируется в кэш. Таким образом, операции записи не кэшируются.

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

А теперь давайте посчитаем уровни кеширования, которые могут быть задействованы в современном сервере и риски, которые несет каждый из них.

1. Уровень кеширования приложения. Наиболее яркий пример – SQL-сервер, который при наличии достаточного объёма оперативной памяти вполне способен разместить всю базу данных (БД) в этой самой оперативной памяти. Как правило, при стандартных настройках большинство SQL-серверов используют кеширование на запись с отложенной записью, тем самым подвергая данные риску в случае любого сбоя.

2. Уровень кеширования операционной системы. В большинстве случаев операционная система «по умолчанию» позволяет кэширование операций записи на диски в оперативной памяти севера. Одно из самых известных исключений, когда ОС Windows Server блокирует использование кеширования на запись для диска – установка на диск Active Directory. А вот для MS SQL и Exchange кеширование на запись в ОС «по умолчанию» - разрешено. Со всеми вытекающими рисками.

3. Уровень кеширования файловой системы. При больших нагрузках некоторые файловые системы, например NTFS, записывают не файлы, а «сплошную ленту данных». Чаще всего -  при заполнении кэша ОС и его «сбросе» на диск. Затем, «при наличии свободного времени» либо при перезагрузке (обязательно), производят разборку такой «ленты» на составляющие и записывают блоки данных в файлы, которым они принадлежат. Если «сплошные ленты» становятся слишком длинными, или идет обращение к данным, часть которых хранится в этих «лентах» - ОС вынуждена «притормаживать» дисковые операции и производить разборку «сплошной ленты» на файлы. Как правило, риск повреждения данных в этой ситуации минимален, а вот риск неожиданного «проседания» производительности дисковой подсистемы и всего сервера на некоторый временной промежуток – весьма высок.

4. Уровень оперативного кэша RAID-контроллера. Большинство аппаратных RAID-контроллеров содержат встроенный кэш-буфер на основе выделенной и размещенной на контроллере оперативной памяти объемом 64MB-1GB. Которая «по умолчанию» включена как кэш на чтение. При наличии в RAID-контролера аккумулятора (BBU) или суперконденсатора – появляется возможность использовать этот кэш в т.ч. на запись.
У «порядочных» RAID-контролеров использование кеша на запись без BBU по умолчанию отключено, или даже заблокировано. Чего нельзя сказать о большинстве так называемых «программных», или soft-RAID. В качестве кэш буфера как на чтение, так и на запись, программные RAID используют часть оперативной памяти сервера. Со всеми вытекающими рисками. При этом «по умолчанию» кеширование на запись у soft-RAID, как правило, включено. О чем, безусловно, упоминается где-то и в какой-то документации. И о чем в подавляющем большинстве случаев даже не подозревают пользователи.
Как результат – около 90% обращений в сервис по поводу разрушения RAID и потери данных как раз и приходятся на эти soft-RAID.

5. Уровень SSD кэша RAID-контроллера. Наибольшую распространенность получили технологии использования SSD в качестве кэша Adaptec MaxCache (MaxIQ) и LSI CacheCade. И MaxCache 1.0, и CacheCade 1.0 обеспечивали исключительно кеширование на чтение, не неся никакого риска для данных. Зато позволяли повысить производительность дисковой подсистемы от 30% до 11 раз, в зависимости от приложений.  MaxCache 2.0 и CacheCade 2.0 уже способны обеспечивать кеширование и на чтение, и на запись (MaxCache 2.0 исключительно для RAID 0). При этом производительность дисковой подсистемы может возрастать до 16 раз!
Если есть кеширование в SSD на запись – автоматически возникает вопрос защищенности от сбоев по питанию самого SSD. К примеру, такие модели, как Intel SSD 320 series и Intel SSD 710 series содержат в себе суперконденсатор, и сбоев по питанию не боятся. А модели  Intel SSD 330 series и Intel SSD 520 series такой защиты по питанию не содержат. Так что, выбирая SSD диски для MaxCache 2.0 и CacheCade 2.0, и включая кэширование на запись, нужно хорошо понимать, какой SSD там установлен.

6. Уровень кеширования на HDD/SSD.  Все современные HDD и SSD содержат кэш в виде энергозависимой оперативной памяти объемом 32-64MB. Который успешно используется для переупорядочивания команд на чтение и запись, а также для кеширования на чтение… и запись. Причем, в стандартной поставке дисков что SATA, что SAS, что SSD этот кэш на запись на самом диске «по умолчанию» как раз включен. А его отключение – требует приложения некоторых усилий и, как правило, использования специализированных утилит производителя диска. Исключение – отказоустойчивые дисковые массивы, в которых поставщик массива модифицирует прошивки диска и просто блокирует кэширование на запись.
Рисков потери данных при аварийном отключении питания лишены модели современных SSD, снабженные суперконденсаторами.

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

P.S.: Данный материал предоставляет в структурированном виде информацию, изложенную в предыдущей статье «Твердые телом».