Замена выпавшего диска в Ceph:Jewel

Для начала надо удалить диск с кластера.

На ноде управления исполняем:

ceph osd out ID

Где ID это номер osd мертвого диска.

На самой ноде с osd исполняем:

systemctl stop ceph-osd@ID

И на головной ноде полностью выводим osd из кластера:

ceph osd crush remove osd.ID
ceph auth del osd.ID
ceph osd rm ID

Теперь выключаем сервер, изымаем диск и вводим новый.

Смотрим привязки дисков и определяем где лежат журналы. На ноде с osd исполняем:

ceph-disk list | grep journal

Так мы увидим какой журнал подключен к какому диску.

Удаляем партицию с журналом с диска с журналами.

parted /dev/диск_с_журналом rm номер_партиции

Заводим диск в кластер.

Замечание: после создания новой ceph-osd номер партиции журнала будет не прежним а больше на 1 самого большого номера на диске с журналом. То есть, если на диске с журналами было 10 партиций, мы удаляем например 1-ю, то новая партиция будет на месте 1-й партиции но с номером 11 (появится дырка в нумерации разделов).

Замечание: также обнаружится, что вывод команд ceph osd tree и ceph osd df tree теряет сортировку. На самом деле там сортировка происходит по порядку создания osd-шек и вывод группируется по серверам.

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

ceph osd create $ID

Потом надо будет их удалить!

ceph osd rm $ID

Далее, на новом диске должна быть partition table типа gpt.

parted /dev/диск_с_данными mklabel gpt

Теперь можно создавать новый ceph-osd и заводить его в кластер.

Замечание: после создания osd-шка сразу начнёт заходить в кластер и начнётся синк. Поэтому желательно после ввода osd поставить ей reweight 0 и постепенно повышать. Так нагрузка на кластер будет минимальной:

ceph osd reweight $ID 0

С головной ноды запускаем (он сам создаст партицию на диске с журналом):

ceph-deploy osd prepare нода:/dev/диск_с_данными:/dev/диск_с_журналом

Все! Мы молодцы, мертвый диск заменен!

Connectivity issues in part of our network in SIN

We experienced connectivity issues in part of our network in our SIN-10 and SIN-11 data centers between 09:25 and 11:35 CEST due to another provider connected to Equinix SG1 that started announcing all the routes on the Internet. Part of the traffic to our network in SIN was passing through their network and you might have experienced increased latency and packet loss during that time. We stopped advertising our prefixes to that IX and traffic resumed as normal.

Читать дальше →

Zimbra и защита от спама

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



В Zimbra Collaboration Suite защита от спама реализована при помощи свободно распространяемого программного комплекса Amavis, реализующего SPF, DKIM и поддерживающего черные, белые, а также серые списки. Помимо Amavis в Zimbra используются антивирус ClamAV и спам-фильтр SpamAssassin. На сегодняшний день именно SpamAssassin является оптимальным решением для фильтрации спама. Принцип его работы заключается в том, что каждое входящее письмо проверяется на соответствие регулярным выражениям, характерным для нежелательных рассылок. После каждой сработавшей проверки SpamAssassin присваивает письму определенное количество баллов. Чем больше баллов наберется под конец проверки, тем выше вероятность того, что анализируемое письмо является спамом.

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



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

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

Подключается такая система с помощью простой подмены ip-адреса POP3-сервера для входящей почты в MX-записи сервера на ip-адрес вашего облачного решения. Иными словами, если раньше MX-запись локального сервера выглядела примерно так:

domain.com. IN MX 0 pop
domain.com. IN MX 10 pop
pop IN A 192.168.1.100

То после замены ip-адреса на тот, что предоставляет вам поставщик услуг облачной безопасности (допустим, что он будет 26.35.232.80), запись изменится на следующую:

domain.com. IN MX 0 pop
domain.com. IN MX 10 pop
pop IN A 26.35.232.80

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

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