Благодаря чему исключена утеря данных с файлового сервера бизнес направления

4.2.1. Откат транзакций

Транзакцией называется совокупность
трех действий:

• чтение данных;

• обработка данных;

• запись данных.

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

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

Для повышения надежности
современные операционные системы (ОС)
содержат специальную систему прослеживания
транзакций TTS (Transaction
Tracking System).
Эта система следит за транзакциями и в
случае аварии сервера при повторном
его запуске ликвидирует все действия,
выполненные незавершенной транзакцией.
В этом случае произойдет так называемый
откат транзакции.

4.2.2. Зеркальные диски

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

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

Дополнительно используется
так называемое горячее резервирование
дорожек диска (Hot Fix).
На диске выделяется область «горячего»
резервирования. Если в процессе работы
на диске обнаруживается дефектная
дорожка, она динамически заменяется
дорожкой из области резервирования.

4.2.3. Резервирование дисков и каналов

При использовании зеркального
диска есть вероятность повреждения
единых для обоих дисков канала, контроллера
и блока питания. ОС может резервировать
целиком каналы, при этом используются
два контроллера, к которым соответственно
подключены два диска. Для питания этих
контроллеров и дисков используются два
блока питания.

4.2.4. Горячее резервирование серверов

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

Выход из строя одного сервера
не влечет за собой остановку работы
сети – в дело автоматически включается
резервный сервер. Благодаря высокоскоростному
каналу связи (по коаксиальному кабелю
длиной до 33 м или оптоволоконному кабелю)
диски резервного сервера содержат те
же файлы, что и диски основного, поэтому
никакого восстановления данных не
требуется. Можно ремонтировать один из
двух используемых серверов без остановки
всей системы, что очень важно, если
система должна работать круглосуточно.

4.2.5. Управление доступом

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

Давайте разберемся, как не допустить потерь. Рассказываем, как защититься от утечки данных и что делать, если она все-таки произошла.

Почему защита от утечек данных важна

Когда мы готовили статью, столкнулись с тем, что представители малого бизнеса не понимают, зачем им нужна защита от утечек данных. «Кому мы вообще нужны? С сотрудниками заключаем договор, а на почту и CRM устанавливаем пароли» — одно из распространенных мнений.

Это — то самое русское «авось». Надежда, что небольшая компания с прибылью около 100 000 рублей в месяц никому не нужна и никто не будет воровать у нее какие-то данные. А когда надежда испаряется и данные все-таки крадут, что-то делать уже поздно.

Приведем один из распространенных сценариев, по которому у вас могут украсть данные. Злоумышленники взламывают CRM и получают доступ к базе данных клиентов. Потом делают сайт точь-в-точь как у вас и регистрируют похожий адрес электронной почты. А затем рассылают клиентам предложение, от которого нельзя отказаться: например, письмо с уведомлением о скидках в 60%. Ваши клиенты переходят на сайт и оплачивают товары, думая, что покупают их у вас. Злоумышленники получают прибыль, клиенты теряют деньги, вы тонете под волной негатива. Это называется фишингом, но вам от этого не легче.

Еще один возможный сценарий — размещение ссылки на вредоносный сайт. Так же, как и в предыдущем случае, злоумышленники взламывают CRM и получают email ваших клиентов. А потом рассылают им письма со ссылкой на вредоносный сайт, который крадет пароли пользователей. Злоумышленники получат пароли и смогут, например, украсть деньги с электронных кошельков людей. А вы получите тонну негатива, потому что письмо будет якобы от вас.

Пройдемся по статистике. Cybersecurity Ventures в ежегодном официальном отчете указали, что каждые 14 секунд во всем мире происходят атаки хакеров. К 2021 году они будут происходить каждые 11 секунд, а общий ущерб от киберпреступности достигнет 6 триллионов долларов в год. А специалисты компании InfoWatch рассказали, что только за прошлый год в сеть утекло более 14 млрд конфиденциальных записей. При этом в России число утечек возросло на 40% по сравнению с прошлым годом, тогда как во всем мире только на 10%.

В прошлом году в России было много скандальных утечек — в сеть «уплывали» базы данных 30 млн автовладельцев, 20 млн налоговых деклараций, 9 млн абонентов «Билайна». И если вы не хотите, чтобы очередная хакерская атака или человеческое недомыслие коснулись вас, читайте дальше. Если продолжаете уповать на «авось», посмотрите хотя бы информацию о том, что делать в случае утечки данных.

Как предотвратить утечку коммерческих данных

Профилактика — наше все. Грамотная защита от утечек данных поможет предупредить негативные последствия, которые могут серьезно повлиять на ваших клиентов и репутацию.

Предотвращаем внутренние утечки данных

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

Используйте NDA. Так называют договор о неразглашении коммерческой тайны. Сначала нужно ввести режим защиты коммерческой тайны и четко прописать, что относится к таким сведениям. А затем подписать с каждым сотрудником NDA и обязательно получить подписи работников на документах, относящихся к коммерческой тайне. А в договоре прописать ответственность работников за нарушение. Это чуть умерит пыл предприимчивых дельцов — никто не захочет таскаться по судам и выплачивать 1–2 миллиона рублей компенсации за то, что скинет какие-то данные «на сторону».

Установите DLP-систему. Это технически сложное автоматизированное решение — специальное программное обеспечение, отслеживающее попытки передачи информации посторонним. На корпоративный сервер и все устройства в офисе устанавливают программу, которая в режиме реального времени проверяет все операции и блокирует подозрительные. Например, если сотрудник попытается отправить таблицу Excel с контактами клиентов с корпоративной почты на личную. DLP-система остановит отправку и сразу уведомит о нарушении того, кто ответственен за защиту от утечек данных.

Единственный недостаток DLP-системы — то, что ее невозможно установить на все личные устройства сотрудников. Они смогут сфотографировать что-то на смартфон или записать разговор на диктофон.

Разграничивайте доступ. Один из самых простых способов обезопасить ценную информацию — разграничивать доступ к данным и давать сотрудникам только то, что им нужно для работы. Например, передавать менеджеру не всю базу, а только контакты клиентов, которых он ведет. Или настроить уровни доступа к документации — это можно сделать в CRM-системе.

Наблюдайте за сотрудниками. Это можно сравнить с DLP-системами, но на самом деле решение работает по-другому. Вы просто устанавливаете в офисе видеонаблюдение и прослушивающие устройства, а на ПК — программы для контроля всего, чем занимается сотрудник. Например, ПО для записи всего происходящего на экране. А потом можно самому просматривать и прослушивать записи, чтобы узнать о факте утечки. Это долго и дорого, но подобное решение можно использовать в качестве одного из этапов защиты. Сотрудникам будет психологически некомфортно красть данные, если они знают, что за ними наблюдают.

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

Эти способы защиты сработают лучше, если использовать их комплексно. Например, создать нормальные условия для сотрудников, подписывать с ними NDA и дополнительно установить DLP-систему.

Предотвращаем внешнюю утечку

Внешние утечки — это когда кто-то извне ворует информацию, не связываясь с вашими сотрудниками. Например, взламывает почту или получает доступ к CRM, ворует документы из офиса. С этим тоже можно и нужно бороться.

Устанавливайте сложные пароли. Это — самое простое решение, которое часто игнорируют. И делают пароли типа «12345». Их подберет даже школьник, который играючи попытается получить доступ к почте, указанной на вашем сайте. Поэтому используйте генераторы паролей. И храните их там, куда очень сложно добраться: лучший вариант — в вашей голове.

Используйте корпоративную почту. Бесплатные почтовые агенты — не зло, но они не подходят для работы с важными коммерческими данными. Их легко взломают, особенно если этим займется хороший специалист. Купите домен и заведите корпоративную почту, арендуйте почтовый сервер у провайдера или используйте платные агенты.

Включите двухфакторную аутентификацию. Двухфакторная аутентификация — это когда чтобы зайти в систему, надо указывать не только пароль, но и другой способ идентификации, например одноразовый код из смс, уведомление на экране смартфона, отпечаток пальца. Такую защиту можно установить на почту и в некоторые CRM-системы и сервисы. Это серьезно усложнит жизнь любителям красть коммерческие данные.

Установите антивирус. Еще одно простейшее решение, которое часто игнорируют. Не скупитесь на хороший антивирус — установите его на все ПК в офисе. Он перехватит вирусы, которые «подсматривают» пароли или крадут ценные данные напрямую.

Уничтожайте документы. Безвозвратно удаляйте уже ненужные документы с серверов. А если работаете и с бумажными документами, содержащими ценные сведения, не поскупитесь на шредер. Если просто выкинуть их в мусорку, любой сможет достать их из ближайшего мусорного бака. А особо упорные — еще и из мусоровоза.

Используйте СКУД. Так называют системы контроля и управления доступом на предприятиях. Они защитят офис или производство от проникновения посторонних людей. Одно из самых простых и незатратных решений — установить шлагбаум на проходной и выдать сотрудникам именные пропуска. А еще установить видеонаблюдение: и на проходной, и на всей территории предприятия.

Подумайте о средствах сетевой защиты. Рассказывать о них можно много и долго. Если коротко, они нужны тем, кто хранит важные сведения онлайн. Среди таких есть системы контроля трафика, WAF, межсетевые экраны. У них общая цель — обеспечить легкий обмен информацией внутри компании, но полностью защитить ее от любых проникновений извне.

Используйте IRM. Это — контейнеризация каждого документа, содержащего ценные для вас сведения. Работает это так: к каждому документу привязывается информация о ключах шифрования и доступе. Даже если его украдут (например, на флешке), не смогут прочитать на своем устройстве. Внедрение такого решения обойдется дорого, но оно того стоит, если у вас на руках очень важная информация.

Сделайте шифрование дисков на ноутбуках и планшетах работников (FDE). Без специальных ключей доступа пользоваться устройством будет невозможно — даже если его украдут, все данные будут надежно защищены. Полное шифрование файловой системы особенно актуально для ноутбуков – это позволяет защитить данные от случайной кражи: например, если сотрудник забудет рабочий ноутбук в кафе или аэропорту. Подобными решениями пользуются крупнейшие корпорации типа NASA.

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

Что делать, если утечка уже произошла

Фактически вы ничего не сможете сделать — данные уже в руках у злоумышленников. Если вы пытались как-то их защитить, можно, например, подать на бывшего сотрудника в суд. При грамотно составленных документах и хорошем юристе вы выиграете дело и, возможно, даже сможете взыскать ущерб. Это — лучший для вас сценарий при внутренней утечке данных.
Если произошла внешняя утечка или не можете найти виновного — в принципе не знаете, к кому попали данные — остается только смириться. Конечно, можно попытаться что-то сделать: запустить в СМИ утку о том, что украденные данные бесполезны, объявить награду за поиск похитителя или предложить ему вернуть информацию за хорошее вознаграждение. Но далеко не факт, что хоть что-то из этого сработает. А кроме того, обычно все это — игры птиц крупного полета: компаний с многомиллионным ежемесячным оборотом. Малому бизнесу чаще проще смириться, чем тратить нереальные деньги на то, чтобы вернуть данные и не допустить их распространения и использования.

Что о защите коммерческих данных говорят предприниматели

Мы решили узнать, что о защите от утечек данных думают российские предприниматели. И получили интересные мнения.

Галина Камышанская, руководитель компании 42Clouds, рекомендует обращаться к надежным провайдерам. И дает рекомендации по выбору фирмы, которой можно довериться:

«Есть три нюанса, на которые надо обращать внимание.

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

Техническая поддержка. Это один из ключевых показателей, на которые стоит обратить внимание после стоимости и скорости работы. В обязательном порядке во время тестового периода проверьте, отвечает ли следующим требованиям служба хотлайна:
— Скорость первого ответа — не более 60 сек. От этого зависит, насколько быстро специалисты реагируют на запросы и как быстро смогут устранить неполадки и защитить данные.
— Круглосуточная поддержка. Это одно из обязательных условий для безопасного хранения ваших данных. Форс-мажорные ситуации могут возникать как на стороне клиента, так и на стороне провайдера. Крайне важно своевременно отреагировать и устранить причину возникновения во избежания потери данных.
— Скорость решения задачи не более 1-х суток. Допускается скорость решения до 2-х суток, если задача касается ведения учета в вашей учетной системе. Но провайдер должен обязательно уведомить клиента, что на решение проблемы потребуется дополнительное время.
— Система бекапирования. Попросите предоставить вам копию вашей базы за позапрошлый день. Таким образом вы сможете проверить, действительно ли у них работает система бекапирования, и точно ли в случае форс-мажоров ваши данные останутся целыми. Не у всех провайдеров делаются бекапы на тестовом периоде, поэтому точно проверить это можно будет в первый оплаченный месяц.

Дополнительные инструменты защиты. Не у многих провайдеров есть индивидуальные средства защиты данных клиента. Как пример, в компании 42Clouds создается специальная «Кнопка экстренного отключения». Она очень помогает, когда к клиенту приходят «маски-шоу» с целью забрать данные. В таких случаях с помощью смс-сообщения или фактической кнопки на столе (по желанию клиента) тушится сетевой интерфейс. Сам сервер продолжает работать, но доступ к нему закрывается. Таким образом вся информация остается целой и невредимой, но доступ к ней можно получить только от самого клиента»

Илья Горбаров, СЕО digital-агентства «Атвинта», рассказал о самых простых способах защиты от утечки данных, которые часто игнорируют:

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

Давайте говорить про информацию, с которой мы имеем дело каждый день. Отбросим сложные темы типа перехвата трафика и взлома серверов специально обученными людьми.

Начинать нужно с простого — это пароли. Если у вас CRM, в которой хранятся данные тысяч ваших клиентов, и у руководителя отдела продаж с полным доступом пароль qwe123asd, у меня для вас плохие новости. Подобрать или подсмотреть такой пароль не составляет труда.

Важно не забывать про уволенных сотрудников, которых нужно лишать прав доступа к клиентской базе до увольнения, чтобы не было соблазна прихватить ее с собой. Если у вас база клиентов хранится в Excel или на Google Диске, вместо облачной CRM с разграничением прав доступа, у меня для вас тоже плохие новости. Скорее всего, ее копия уже есть у менеджеров.

Люди должны обладать минимальной компьютерной грамотностью, чтобы не открывать фишинговые сайты и подозрительные файлы в почте. У нас был случай, когда через зараженный компьютер сотрудника злоумышленники получили доступ к рекламному кабинету в Facebook и слили приличный бюджет до того, как Facebook успел его заблокировать. Деньги нам не вернули, а личный кабинет пришлось заводить новый. Потеряли мы порядка 50 000 рублей, хватило бы на зарплату среднего сотрудника.

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

И не забудьте поменять пароль по-умолчанию у вашего Wi-Fi роутера, админки сайта и… IP-видеокамер наблюдения. Поищите видео по запросу «взлом IP камер пранк», и у вас отпадут вопросы, зачем это делать»

А вы защищаете коммерческие данные компании или надеетесь на «авось»? Поделитесь своим мнением и лайфхаками по защите в комментариях!

Независимо от того, какой марки ваш винчестер, всего лишь вопросом времени является то, когда вам придется восстанавливать потерянную информацию. Не важно, от чего это произойдет — от механического повреждения диска или от чего-то еще, восстановление данных с жестких дисков ноутбуков, одиночных серверов или RAID серверов будет всегда востребовано. В основном данные теряются в силу следующих причин:

• Повреждение данных из-за вируса
• Поломка жесткого диска из-за природных катаклизмов (пожар, наводнение, молния)
• Физическое повреждение жесткого диска, вызванное падением или неаккуратным обращением
• Случайное форматирование не той файловой системы при установке ОС
• Потеря данных вызванных форматированием жесткого диска
• Ошибки одновременной работы нескольких дисков на RAID серверах

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

Если вы хотите уменьшить вероятность потери важных данных, возьмите на вооружение эти простые и дешевые приемы:

1. Делайте резервные копии важных файлов. Если взять в привычку еженедельно или ежемесячно копировать самую важную информацию на DVD (внешний жесткий диск, флеш-память), то совсем небольшие вложения в стопку дисков помогут сохранить важные документы, файл, бесценные фотографии и MP3.

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

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

4. Необходим опыт. Никогда не производите никаких действий, подобных установке жесткого диска или его починке, если у вас нет опыта таких работ. Если вы не знаете, как устанавливать жесткий диск или переустанавливать RAID, то лучше воспользоваться помощью специалиста, вместо того, чтобы случайно потерять важную информацию.

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

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

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

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

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

10. Делайте резервные копии важных файлов. Не лишним будет напомнить еще раз. Использование DVD и внешних USB диски для хранения важной и нужной информации, могут избавить вас от необходимости нанимать специалистов по восстановлению информации на ваших винчестерах и массивах RAID.

Data Recovery — восстановление данных

Физические против Логических катастроф

Прежде всего, существует различие между RPO / RTO для физических и логических катастроф — или иначе, недоступности данных по сравнению с потерей данных. Объясню на основе нескольких примеров:

• Сбой питания центра обработки данных приводит к недоступности данных. Данные попрежнему там, но вы не можете получить доступ к ним. Это физическая катастрофа, которая приводит к недоступности данных.
• Пожар в центре обработки данных сжигает все системы. Данные повреждены и всё, что бы вы ни делали, они не станут снова доступными. Вы должны полагаться на своего рода копии этих данных, которые хранятся где-то в другом месте, чтобы иметь возможность восстановиться. Это физическая катастрофа, которая приводит к потере данных.
• Пользователь вызывает случайное удаление транзакций или файлов. Это логическая катастрофа, которая приводит к потере данных.
• Программная ошибка в кластерном ПО вызывает полный выход из строя всего кластера.

Это логическая катастрофа, которая приводит к недоступности данных.

Логические катастрофы не требуют дополнительных центров обработки данных с дополнительным оборудованием для восстановления данных. Если вы каким-то образом делаете частые копии данных (обычно известно как стратегия «Backup», хотя и более инновационные и элегантные пути становятся доступными), то вы можете восстановиться локально.

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

Давайте пока сосредоточимся на физических катастрофах.

Нулевые потери данных — Нулевое время простоя

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

Что касается RPO, то всегда был консенсус, что синхронное зеркалирование данных (или репликация) некоторого вида покрывает все ваши потребности. На самом деле EMC была самой первой, кто предложил синхронное зеркалирование устройств хранения данных с помощью продукта EMC SRDF, примерно в 1995 году. На уровне устройств хранения данных это гарантирует «нулевые потери данных», потому что каждая операция записи ввода/вывода в основную систему хранения данных (источник) будет подтверждена только тогда, когда эти данные также доставлены и подтверждены резервной системой (цель). Пока канал передачи данных функционирует, обе системы — исходная и целевая всегда на 100% синхронизированы, поэтому любая транзакция, записанная основным приложением, гарантированно также будет записана и на целевом (D/R) сайте. В случае (физической) катастрофы база данных будет прервана (крах) и должна быть перезапущена на резервном сайте, используя зеркальный набор данных. Для данных, не являющихся базами данных, например, файловые системы (содержащие плоские файлы) – они также должны быть смонтированы на резервном сайте — но все данные будут представлены именно так, как это было прямо перед катастрофой.

До сих пор — это в теории. Давайте посмотрим, как это в реальности и как Закон Мерфи портит наш идеальный мир.

Целостность, Коммитмент & Откат

Прежде всего, реляционные базы данных (RDBMS, основанные на принципах ACID- Atomicity, Consistency, Isolation, Durability) используют концепцию применить и подтвердить (а иногда и откат) для транзакций. Так приложение может создать или обновить запись транзакции, но не подтверждать (commit) транзакцию некоторое время. Если база данных неожиданно прерывается (нормально или ненормально), прежде чем приложение подтвердило транзакцию, то в целях сохранения целостности базе данных придется «откатить» эту транзакцию к старому состоянию. Это означает, что на уровне базы данных нулевая потеря данных справедлива только для подтвержденных транзакций. Все неподтвержденные транзакции будут потеряны (из-за отката). Эта концепция имеет серьезные последствия для приложений. Если вы хотите реальные нулевые потери данных из конца в конец для вашего приложения баз данных, это означает, что код приложения должен быть написан таким образом, чтобы каждая транзакция, которая не должна быть потеряна, должна быть подтверждена немедленно.

Если приложение нарушает этот закон (из-за оптимизации производительности или, может быть, из-за лени/неосведомленности разработчика), то нулевая потеря данных не гарантируется на 100%.

Таким образом, в теории, с идеально написанным кодом приложений, это не должно быть проблемой. К сожалению, я не встречал такое идеальное приложение нигде за все время моей ИТ-карьеры.

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

Так что будьте готовы, что даже при нулевой потере данных при (синхронном) зеркалировании, вы можете потерять некоторые данные после катастрофы. Тем не менее, большинство корпоративных СУБД обеспечивают целостность данных после перехода на другой ресурс.

Нулевая потеря данных в файловых системах

Теперь давайте поговорим о еще большем мифе: файловые системы. В старые времена, файловые системы необходимо было сканировать на проблемы целостности после аварии (помните Windows CHKDSK, CHKNTFS, UNIX fsck и «потерянные+найденные» и эти проверки могли идти часами и часами после сбоя?). Чтобы преодолеть это, многие современные файловые системы имеют средства ведения журналов, которые ведут себя очень похоже на средства ведения журналов баз данных. Они обеспечивают, что при изменении метаданных файловой системы, это изменение записывается в системный журнал файла, так что если файловая система должна быть восстановлена после аварии, то не нужно будет сканировать весь набор данных. Вместо этого, он быстро вновь применит все изменения из журнала и в течение нескольких секунд вы снова в работе. Так что, может показаться журналированные файловые системы предотвращают потерю данных. Но реальность сильно отличается …

Рассмотрим файловый сервер, используемый для сохранения больших документов Office. Вы как конечный пользователь открываете большой (т.е. 10 МБайт) документ PowerPoint и начинаете редактирование. После этого, когда вы нажимаете «Сохранить», чтобы подтвердить изменения в файл-сервере и его файловой системе. Приложение PowerPoint теперь начинает перезаписывать полный документ, но на полпути в 5 Мб случается авария/катастрофа и срабатывает переключение на резервный ресурс. Резервный сервер монтирует зеркальную копию файловой системы, только чтобы обнаружить, что она не была чисто размонтирована и воспроизводит записи журнала, чтобы вновь сделать файловую систему целостностной. Он находит новый размер PowerPoint файла, времена изменений, другие мета-данные и повторно применяет их на восстановленную файловую систему. Но 10 МБ файл в настоящее время содержит только 5 Мегабайт наполовину сохраненного приложением PowerPoint и еще 5 мегабайт старого файла, прежде чем он был перезаписан. Как вы думаете, что произойдет если вы попытаетесь открыть эту PowerPoint презентацию снова?

В попытке обойти эту проблему, некоторые файловые системы предлагают «данные в журнале» опции для монтирования. Это означает, что не только метаданные (время доступа / изменения, размер файла, владельца / группу и т.д.), но и сами данные записываются в журнале перед записью в реальный файл. Но это не предохраняет файлы от ситуации, когда они только наполовину записаны (если только журнал не сбрасывается в реальный файл сразу после закрытия приложением обработки файла). Накладные расходы (влияние на производительность) этой опции монтирования огромны и вряд ли кто использует его. Чтобы добавить к путанице; некоторые действительно современные файловые системы, кажется, решили эту проблему, потому что они всегда пишут в журнал (как SUN ZFS), но вы все еще рискуете при частично записанных файлах. Не попадите в эту (маркетинговую) ловушку.

Местное или Удаленное восстановление

Теперь, чтобы прояснить некоторый другой миф: Коренная причина этих проблем с повреждением данных / потерей транзакций вызваны дизайном приложения или системы. Если система спроектирована из конца в конец так, чтобы иметь возможность выжить в случае сбоев электропитания без потери данных, то тогда инструменты репликации EMC (SRDF, Mirrorview, RecoverPoint и т.п.) также могут обеспечить нулевые потери данных, теперь и на удаленном расстоянии. Иногда я слышу утверждения, что даже с зеркалированием от EMC Вы можете не получить целостность данных после сбоя и переключения на резервный. Но если это так, то то-же самое верно и для выхода из строя сервера и сбоев питания, и первопричина проблемы находится в стеке приложений, а не в методе репликации. Если ваше приложение может пережить падение сервера без повреждения данных, тогда не имеет значения, восстанавливаетесь ли вы локально или на удаленной D/R площадке (учитывая, что вы используете технологии обеспечения целостности для репликации).

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

Катастрофы в теории и в реальности

Если вы читаете официальные документы или маркетинговые материалы по D/R продуктам, вы часто будете видеть преимущества этой технологии, предполагая какую-то одну огромную катастрофу. Классическая – гигантский аэробус врезается в ваш центр обработки данных. Взрыв газа. Массовое отключение электропитания. Во всех этих случаях, часто делается предположение, что вы переходите от полнофункционального центра обработки данных к полностью разрушенному в прах в течение одной микросекунды. Реальность же сильно отличается. В EMC мы называем эти реальные бедствия «Катящиеся Катастрофы». Это означает: проблема сначала возникает небольшая, а затем становится все более и более серьезной в течение определенного периода времени (минуты или несколько часов). Чтобы понять мою точку зрения, рассмотрим, например, пожар в центре обработки данных, который начинается с небольшого возгорания в углу. Огонь начинает расти все больше и выжигает некоторые из каналов глобальной сети, которые используются для D/R зеркалирования в другом центре данных. Репликация приостановлена, но, как правило, политика установлена такой, что производственная система позволяет продолжать обработку данных. Через пять минут огонь достигает серверов и приложения падают (я не пойду настолько далеко, рассматривая, что сервер, который работает перегретым, может привести к повреждению данных, прежде чем наконец произойдет его полный отказ — из-за перегретых процессоров, оперативной памяти, материнских плат, адаптеров Ввода/Вывода или оплавленных кабелей). Итак, несмотря на ваше дорогое зеркалирование с нулевой потерей данных, теперь у вас есть основной центр обработки данных с более поздними данными, чем (целостная) копия на вашем D/R сайте. Теперь вы должны переключиться на резервный центр и смириться с несколькими минутами (или более) потери транзакций… (обратите внимание, что в EMC у нас есть некоторые инновационные решения чтобы справиться с этой проблемой — но это уже выходит за рамки этого поста).

Между прочим, если вы в состоянии потушить пожар и отремонтировать серверы (при условии, что устройства хранения данных находятся по-прежнему там), то как вы собираетесь переключаться обратно? У вас сейчас есть записанные обновления данных независимо друг от друга на обоих сайтах – а большинство инструментов репликации будет просто не в состоянии выполнить инкрементальную ресинхронизацию — или что хуже, вызовут скрытые повреждения данных при переключении назад …

Синхронный или Асинхронный

Так почему же мы до сих пор предпочитаем синхронное зеркалирование для приложений? Особенно когда синхронные операции записи вызывают снижение производительности (то есть операция записи должна быть направлена на удаленную систему D/R и подтверждение от нее должно вернуться обратно прежде, чем мы сможем приступить к следующей транзакции)?

Мое мнение, что это в основном вопрос наследия. EMC была первой, предложившей синхронное зеркалирование, и так он стал де-факто стандартом для многих организаций. Другие производители догнали EMC и частично обогнали EMC, предлагая асинхронную репликацию. С асинхронной репликацией вы не ждете подтверждения и просто продолжаете работу со следующей транзакцией, так что теоретически не существует больше никакого влияния на производительность. Проблема была в том, что порядок, в котором вы обрабатываете операции записи Ввода/Вывода, имеет критическое значение для обеспечения целостности данных. Вкратце: если вы измените (рандомизируете) порядок операций записи, то ваши данные на D/R сайте полностью бесполезны и не годятся для восстановления бизнеса в случае аварии. Для того чтобы поддерживать согласованность транзакций, конкурирующие производители должны были реализовать в своих решениях либо соблюдение очередности операций записи Ввода/Вывода — в результате чего процесс репликации становится однопоточным, вызывая огромные узкие места — либо маркировки каждой отдельной операции Ввода/Вывода с помощью временной метки или идентификатора последовательности — вызывая массивную дополнительную нагрузку на каналы репликации. Оба метода оказалась слишком непрактичными для высокопроизводительных сред.
Некоторые реализации асинхронной репликации вообще не гарантировали порядок операций Ввода/Вывода, и они были в основном бесполезны для правильной стратегии D/R. Существование таких вот методов, вероятно, и вызвало миф, что Асинхронная репликация не годится вообще.

Вот почему ЕМС ждала долгое время, прежде чем предложить свой вариант асинхронного зеркалирования (SRDF/A), и мы наконец сделали возможным достижение целостности при асинхронном зеркалировании без влияния на производительность, в основном с помощью расположенных в оперативной памяти буферов применить /подтвердить и своего рода контрольных точек (я пропущу детали, но просто примите к сведению, что это работает как было запроектировано).

Значение RPO, которое мы можем достичь при асинхронной репликации, в два раза превышает время цикла для контрольных точек. Так что, если вы установите время цикла в 1 минуту, то ваш RPO будет 2 минуты (в худшем случае). Это означает, что после переключения при аварии вы потеряете 2 минуты последних транзакций. Все данные будут по-прежнему 100% действительны и целостные. Значение RTO (время переключения/ восстановления) не сильно изменится. Итак, асинхронное зеркалирование не так уж плохо для многих приложений (учитывая, что всего лишь несколько лет назад мы опирались на перенос носителей и восстановление с магнитных лент – что обычно вело к RPO равному 24 часа или более — если восстановиться удавалось успешно, что было не всегда).

Бизнес-требования

Итак, если Асинхронная репликация (EMC) гарантирует согласованность транзакций, и только вызывает рост значения RPO от нуля (теоретически) до нескольких минут, и еще снижает дополнительную нагрузку на производительность приложения до нуля, то почему же большинство организаций по-прежнему предпочитает использовать 100% синхронную репликацию?

ИМХО, для более 95% всех бизнес-приложений асинхронное зеркалирование более чем достаточно. Исключение составляют те среды, где секундная стоимость транзакций представляет большую ценность для бизнеса — это в основном относится к финансовому процессингу, при котором одна транзакция может представлять миллионы долларов (или любую другую валюту), но я также могу думать и о нескольких нефинансовой приложениях, где ценность отдельных транзакций очень высока.

Вернемся опять к людям бизнеса, которые снова просят мифические нулевые потери данных. Спросите их, какое влияние на бизнес будет, если потерять данные последних 5 минут. Могут ли они выразить это в стоимости денег? Хотя это трудно, вы можете по крайней мере попытаться вычислить приблизительное значение на основе некоторых предположений.

Теперь, если стоимость синхронной репликации (влияние на производительность, более дорогие каналы связи для репликации, требуемые дополнительные приложения/ настройки системы и т.д.) выше, чем стоимость тех немногих минут транзакций, то моя рекомендация идти с асинхронной репликацией (которая будет в результате, как сказано, в более 95% всех случаев).

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

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

Заключительный миф: Катастрофы очень маловероятны

Кстати, фото в начале этого поста с Costa Concordia, и я плавал в круизе на этом судне с женой за 6 месяцев до его катастрофы. Я до сих пор помню, как мы однажды вечером, медленно гуляя по боковой палубе в середине Средиземного моря, глядя на спасательные шлюпки над нашими головами, и я сказал ей, что они, вероятно, никогда не используют их, потому что современные круизные суда очень безопасны …

Обновление: Я получил сообщение от одного из моих клиентов (спасибо Саймон!), что я представил дело так, будто SRDF / Asynchronous является новой функцией EMC. Для того чтобы избежать путаницы: Асинхронный режим (с обеспечением целостности набора данных) был предложен где-то в 2001/2002 годах (проверьте здесь), так что он был уже в течение некоторого времени.