Всем привет, меня зовут Юрий Лазарев, я системный администратор Облака Mail.Ru. Недавно мы внедрили автоматическое антивирусное сканирование всех загружаемых в хранилище файлов. Теперь весь контент проверяется Антивирусом Касперского, чья продукция уже используется для защиты от вирусов в Почте Mail.Ru. Кроме того, были просканированы файлы, залитые в Облако с момента его запуска в прошлом году. Реализовать подобную проверку в условиях высоконагруженного сервиса, сохраняя при этом такую же высокую скорость работы, — достаточно сложная задача.
В качестве аналогии можно сравнить процесс строительства одноэтажного дома и небоскрёба. Одноэтажный дом может построить даже человек без глубоких знаний и большого опыта, и эта конструкция будет худо-бедно стоять и служить. С небоскребом все гораздо сложнее: конструкцию такого здания необходимо серьёзно просчитывать с точки зрения несущей способности грунта, ветровых нагрузок и множества других факторов. Так и антивирусная проверка в облачном сервисе организована совсем не так, как на домашних компьютерах или даже в корпоративных сетях.
Если вы хотите поподробнее узнать, что представляет собой архитектура Облака, то можно почитать предыдущую статью на Хабре. Это даст понимание того, как протекает процесс сохранения файла и его заливка в Облако. А здесь мы опишем, как нам удается проверять на вирусы петабайты данных в нашей высоконагруженной системе, не теряя при этом ни в качестве работы сервиса, ни в скорости загрузки и проверки файлов.
В Облаке существует дедупликация, то есть файл с конкретным содержимым присутствует лишь в одном экземпляре (на самом деле в двух, так как существует резервная копия). Если 200 человек зальют один и тот же файл, то в хранилище не будет находиться 200 одинаковых файлов. Просто всем этим пользователям будут раздаваться копии одного файла. Зачем? Во-первых, это позволяет нам эффективнее использовать место на дисках и, как следствие, предлагать пользователям больше бесплатного пространства для хранения информации. Кроме того, мы экономим мощности для проверки файлов. На данный момент дедупликация позволяет нам снизить нагрузку на хранилище примерно на 15%.
Проверка осуществляется несколько раз: как только файл попадает в Облако и позже, с помощью обновленных антивирусных баз. Ведь всегда есть вероятность, что файл заразился новым вирусом, который ещё не был известен антивирусу на момент загрузки. Так что проверки проводятся на постоянной основе. Если файл инфицирован, сервис не позволит ни произвести скачивание, ни создать на него ссылку.
Мы проверяем файлы на отдельных серверах, которые выделены исключительно под эту задачу. Кроме того, мы написали утилиту, которая позволяет проверять файлы, используя API Касперского. Дело в том, что нельзя просто так поставить коробочную версию антивируса на какой-нибудь сервер и сказать ему, чтобы он проверял все файлы. В этом случае можно будет вообще забыть о таком явлении, как высокая производительность. Антивирусный продукт не является инструментом, специально разработанным для использования в облачных системах, его необходимо интегрировать. И самим процессом антивирусной проверки в высоконагруженных системах необходимо жёстко управлять. Эту роль на себя взяла вышеупомянутая утилита. Она не только определяет последовательность проверки файлов, но и оптимизирует нагрузку. Если описать по-простому: не надо загружать весь файл из хранилища и передавать на проверку. Утилита берет начало файла, скачивает определенный кусочек из хранилища. Дальше Касперский анализирует тип этого файла. Как правило, нет смысла проверять все тело файла целиком. В зависимости от типа файла SDK антивируса определяет стратегию проверки. Дальше идёт запрос в нашу утилиту, мол, дай мне этот кусок, и нужная информация загружается из хранилища. В итоге, когда SDK решает, что файл проверен, тот получает отметку о самом факте проверки, указывается время её проведения и версия антивирусной базы. Таким образом, использование управляющей утилиты существенно сокращает время проверки, снижает нагрузку на сеть и на сами диски.
На данный момент у нас более 20000 дисков с файлами пользователей Облака. И проверка ведется постоянно. В хранилище попадают самые разные данные, включая огромные видеофайлы. Вытаскивать их из хранилища и перегонять по сети было бы крайне неоптимальной тратой ресурсов. Но, благодаря описанному выше механизму, нам удалось наладить антивирусную проверку силами нескольких десятков серверов. Сейчас в сутки проверяется около 8 млн файлов, порядка 50 терабайт. Это далеко не пиковая производительность системы, к тому же мы заложили возможности по дальнейшему масштабированию.
Итак, мы снижаем стоимость хранилища и нагрузку на неё за счёт использования дедупликации, а также существенно увеличиваем скорость антивирусной проверки с помощью управляющей утилиты. Но этого было бы недостаточно для быстрой обработки столь большого объёма данных. Поэтому мы применили ещё один инструмент — очередь проверки. Она представляет собой не просто список файлов, в который снизу добавляются данные, это отдельный сервис. Сама очередь находится на отдельном сервере и работает под управлением СУБД Tarantool. Это собственная разработка сотрудников Mail.Ru Group, и одной из её особенностей является очень высокая производительность. Именно это стало определяющим фактором при выборе СУБД, а вовсе не её происхождение. Прежде всего, в очередь попадают новые файлы, загружаемые в Облако. Их туда помещает сервис-загрузчик. А также в очередь добавляются файлы с самым большим временем, прошедшим с момента их последней проверки. У второго сервиса, пополняющего очередь проверки, есть ограничение на максимальное количество добавляемых старых файлов, чтобы он не замедлил процесс проверки новых. На каждом сервере одновременно работает несколько таких сервисов обработки. Сейчас мы пробуем распределять файлы разных типов и размеров по разным очередям, чтобы еще сократить время проверки для большинства загружаемых файлов.
В связи с тем, что автоматическая проверка была внедрена через некоторое время после запуска Облака Mail.Ru, накопилось порядка 14 петабайт данных, которые нужно было проверить. Причем, естественно, они лежали не на одной машине, а были раскиданы по нескольким дата-центрам. Ситуация осложнялась тем, что все эти серверы активные, а значит нельзя было нагружать их задачами по проверке файлов. Если сервер, на котором хранятся файлы, будет занят какими-то аналитическими задачами, которые нагружают аппаратные ресурсы хранилища, то потенциально скорость выполнения всех операций существенно уменьшается, в том числе, и передача файлов по сети. И в таком случае мы получили бы деградацию качества сервиса.
Проверять такой объем данных постепенно тоже было бы нецелесообразно, на это ушло бы слишком много времени. Поэтому решено было задействовать дополнительные ресурсы, чтобы провести проверку в кратчайшие сроки. Для этой цели был собран временный кластер из 60 серверов. Они и осуществили проверку всех ранее загруженных данных примерно за три недели.
Также мы посчитали, какие заблокированные вредоносные программы наиболее распространены:
Итак, благодаря комплексному применению управляющей утилиты, очереди проверки и СУБД Tarantool, нам удалось добиться высокой производительности антивирусной проверки, почти в реальном времени, задействовав сравнительно небольшие ресурсы.
Тенденция такова, что со временем все больше пользовательской информации будет храниться в облаках. Поэтому антивирусная проверка становится неотъемлемой частью не только устройств пользователей, но и онлайн-сервисов, где хранятся их данные.
Механизм проверки в нашем Облаке мы ещё будем существенно модернизировать. Например, планируется ввести удельный вес. Благодаря этому параметру чаще всего будут проверяться наиболее востребованные пользователями файлы. Файлы большого размера будут выделяться в отдельную очередь, поскольку их проверка занимает очень много ресурсов и времени. Организация подобных очередей для разных файлов – это интересная задача, о которой мы расскажем в одном из следующих постов.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий