Хорошего DevOps-инженера непросто найти, трудно недооценить и ещё сложнее — заменить. Спрос на специалистов стабильно превышает предложение, а зарплаты — в числе самых высоких в IT.
Если хотите развиваться в профессии с высоким потенциалом, начните с курса Нетологии «DevOps-инженер с нуля». Уже через 6 месяцев вы сможете трудоустроиться сисадмином, параллельно осваивая навыки DevOps.
В результате научитесь:
👉 работать с Docker, Kubernetes, Jenkins и Git;
👉 настраивать CI/CD и мониторинг инфраструктуры;
👉 администрировать Linux, Windows и базы данных;
👉 использовать облачные технологии и микросервисы.
Вас ждут минимум 4 проекта в портфолио, бесплатный доступ к Yandex Cloud и 10 QA-сессий с экспертами из Alibaba Group, ВКонтакте и Ozon, где сможете задать любые вопросы о профессии.
А чтобы быть ещё конкурентоспособнее, вы подтянете английский и познакомитесь с основами Python.
Сейчас на курс действует скидка 40% — записывайтесь 💡
Реклама. ООО "Нетология". ИНН 7726464125 Erid 2VSb5yvgeLR
Если хотите развиваться в профессии с высоким потенциалом, начните с курса Нетологии «DevOps-инженер с нуля». Уже через 6 месяцев вы сможете трудоустроиться сисадмином, параллельно осваивая навыки DevOps.
В результате научитесь:
👉 работать с Docker, Kubernetes, Jenkins и Git;
👉 настраивать CI/CD и мониторинг инфраструктуры;
👉 администрировать Linux, Windows и базы данных;
👉 использовать облачные технологии и микросервисы.
Вас ждут минимум 4 проекта в портфолио, бесплатный доступ к Yandex Cloud и 10 QA-сессий с экспертами из Alibaba Group, ВКонтакте и Ozon, где сможете задать любые вопросы о профессии.
А чтобы быть ещё конкурентоспособнее, вы подтянете английский и познакомитесь с основами Python.
Сейчас на курс действует скидка 40% — записывайтесь 💡
Реклама. ООО "Нетология". ИНН 7726464125 Erid 2VSb5yvgeLR
👎30👍7
На днях в очередной раз настраивал Proxmox Backup Server (PBS) в режиме синхронизации бэкапов между двумя разнесёнными хранилищами. Там есть некоторые нюансы с правами пользователей, которые приходится уточнять в документации, так что решил написать пошаговую инструкцию. Плюс, поделиться информацией для тех, кто ещё не настраивал подобное, либо вообще не знает о такой возможности.
PBS умеет бэкапить как виртуальные машины с уровня гипервизора, так и файлы внутри виртуальных машин с помощью Proxmox Backup Client. Сервер бэкапов делится на Datastores со своими бэкапами и настройками доступа. Каждый Datastore штатно может быть синхронизован с другим удалённым Datastore на другом PBS. Это позволяет строить распределённые системы хранения данных, где бэкапы синхронизируются автоматически и хранятся в соответствии с заданными локальными политиками хранения. Получается удобная и функциональная распределённая система бэкапов. И при этом полностью бесплатная.
Имеем 2 разных PBS: pbs-local и pbs-remote. На первый бэкапятся виртуальные машины и затем бэкапы синхронизируются в режиме Push на второй сервер. Рассказываю, как это настроить.
1️⃣ На pbs-remote идём в Configuration -> Access Control и создаём пользователя, под которым будет подключаться pbs-local. Велик соблазн везде использовать root и полные права, но не рекомендую так делать. Тут же в разделе Permissions добавляем новому пользователю следующие права:
{store} - название Datastore, куда будут синхронизироваться бэкапы. Можно создавать для каждого Datastore своего пользователя, можно использовать одного для всех. Тут уже решайте сами, как будете дробить доступ.
2️⃣ На pbs-local идём в Configuration -> Remotes и добавляем pbs-remote, используя созданную выше учётную запись.
3️⃣ На pbs-local в разделе Configuration -> Access Control -> Permissions для пользователей локальных Datastore, которые будут синхронизироваться, добавьте права:
4️⃣ На pbs-local идём в Datastore, выбираем тот, что хотим синхронизировать. Переходим в раздел Sync Jobs и добавляем задачу Add Push Sync Job. Выбираем добавленный на шаге 2 remote и выбираем остальные параметры, в том числе расписание синхронизации.
На этом всё. Теперь можно либо дождаться времени выполнения, либо запустить синхронизацию принудительно. По завершении на pbs-remote будет копия всех бэкапов. То есть на обоих серверах раздел Content будет идентичным. Можно подключить pbs-remote к какому-то гипервизору и там проверять восстановление и запуск виртуальных машин. Это удобно делать, расположив PVE и PBS на одном железном сервере. Получается универсальный инструмент и для дополнительной копии бэкапов, и для их проверки.
Отдельно отмечу, что синхронизация хорошо переносит нестабильные соединения. Процесс не прерывается при разрывах связи и её отсутствии в течении нескольких минут. При возобновлении связи синхронизация продолжается.
Ту же самую процедуру синхронизации можно проводить в обратном направлении, то есть по модели Pull, когда удалённый сервер сам подключается к локальному и забирает данные. Можно всё это комбинировать. Например, VM бэкапятся в локальный Datastore, куда и них есть доступ. Потом на этом же PBS эти бэкапы по модели Pull копируются в рамках этого же сервера, но в другой Datastore, куда доступ ограничен. А с этого Datastore бэкапы по Pull или Push копируются на удалённый сервер.
Настройки очень гибкие и зависят от вашей инфраструктуры, режима параноидальности и доступного места для хранения. Напомню, что в каждом Datastore могут быть свои политики хранения бэкапов. Где-то храним 5 последних копий, а где-то 7 дневных копий, 4 недельных и 6 месячных. А куда-то складываем месячные и вообще не удаляем.
В 4-й версии PBS будет ещё пачка приятных нововведений. Например, хранение бэкапов в S3. И всё это бесплатно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #backup
PBS умеет бэкапить как виртуальные машины с уровня гипервизора, так и файлы внутри виртуальных машин с помощью Proxmox Backup Client. Сервер бэкапов делится на Datastores со своими бэкапами и настройками доступа. Каждый Datastore штатно может быть синхронизован с другим удалённым Datastore на другом PBS. Это позволяет строить распределённые системы хранения данных, где бэкапы синхронизируются автоматически и хранятся в соответствии с заданными локальными политиками хранения. Получается удобная и функциональная распределённая система бэкапов. И при этом полностью бесплатная.
Имеем 2 разных PBS: pbs-local и pbs-remote. На первый бэкапятся виртуальные машины и затем бэкапы синхронизируются в режиме Push на второй сервер. Рассказываю, как это настроить.
Path: /datastore/{store}Role: DatastoreBackup{store} - название Datastore, куда будут синхронизироваться бэкапы. Можно создавать для каждого Datastore своего пользователя, можно использовать одного для всех. Тут уже решайте сами, как будете дробить доступ.
Path: /remoteRole: RemoteSyncPushOperatorНа этом всё. Теперь можно либо дождаться времени выполнения, либо запустить синхронизацию принудительно. По завершении на pbs-remote будет копия всех бэкапов. То есть на обоих серверах раздел Content будет идентичным. Можно подключить pbs-remote к какому-то гипервизору и там проверять восстановление и запуск виртуальных машин. Это удобно делать, расположив PVE и PBS на одном железном сервере. Получается универсальный инструмент и для дополнительной копии бэкапов, и для их проверки.
Отдельно отмечу, что синхронизация хорошо переносит нестабильные соединения. Процесс не прерывается при разрывах связи и её отсутствии в течении нескольких минут. При возобновлении связи синхронизация продолжается.
Ту же самую процедуру синхронизации можно проводить в обратном направлении, то есть по модели Pull, когда удалённый сервер сам подключается к локальному и забирает данные. Можно всё это комбинировать. Например, VM бэкапятся в локальный Datastore, куда и них есть доступ. Потом на этом же PBS эти бэкапы по модели Pull копируются в рамках этого же сервера, но в другой Datastore, куда доступ ограничен. А с этого Datastore бэкапы по Pull или Push копируются на удалённый сервер.
Настройки очень гибкие и зависят от вашей инфраструктуры, режима параноидальности и доступного места для хранения. Напомню, что в каждом Datastore могут быть свои политики хранения бэкапов. Где-то храним 5 последних копий, а где-то 7 дневных копий, 4 недельных и 6 месячных. А куда-то складываем месячные и вообще не удаляем.
В 4-й версии PBS будет ещё пачка приятных нововведений. Например, хранение бэкапов в S3. И всё это бесплатно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #backup
Please open Telegram to view this post
VIEW IN TELEGRAM
13👍215👎2
На днях обновились два продукта Proxmox, которые я активно использую: Virtual Environment 9.0 и Backup Server 4.0. Прежде чем перейти к содержанию обновлений, сделаю предупреждение. Не торопитесь обновлять свои сервера. У Proxmox есть некоторый шанс получить проблемы после обновления, особенно для большого обновления со сменой релиза Debian. Я сам лично много раз сталкивался с ними. Делал тут по этому поводу заметки. Плюс, опыт других людей говорит о том же.
Расскажу про своё отношение к обновлению гипервизоров. Если рядом нет подменного сервера, на который можно быстро восстановить работу виртуальных машин, то я его не обновляю без веских оснований. Процесс этот откладываю на максимально комфортное время, когда это можно сделать. Обычно какие-то длинные праздники, типа майских или новогодних. То же самое для кластера. Обновлять надо очень аккуратно и понимать, что ты будешь делать, если он вдруг не переживёт обновление. Уронить прод от неаккуратного обновления гораздо проще, чем получить проблемы от каких-то уязвимостей, которых во-первых, не так много, чтобы это было опасно в закрытом контуре, во-вторых, обновления приходят регулярно и если постоянно обновляться по мере их выхода, то частота этого процесса сама по себе по теории вероятности принесёт рано или поздно проблемы.
Соответственно, вы либо держите тестовый контур, там всё проверяете и регулярно обновляетесь, либо изыскиваете какие-то другие подходы к этому процессу, более безопасные и растянутые во времени. Опять же, если нет чего-то срочного и критичного. Для Proxmox вообще такого не припоминаю. В интернет они у меня никогда не смотрят, и доступ к ним ограничен. Ещё раз подчеркну, что этот подход используется только для гипервизоров. Не для виртуальных машин с рабочей нагрузкой. Их можно относительно безопасно обновлять, так как масштаб бедствия несоизмерим, если что-то пойдёт не так.
📌Ключевые обновления Proxmox VE:
🔥Обычные LVM тома, не Thin, теперь поддерживают снэпшоты. У меня это самый популярный формат хранения. Из-за того, что он не поддерживал снепшоты, иногда приходилось использовать qcow2 диски, но они не очень удобны из-за ряда особенностей. В описании указано, что хранилища типа Directory, NFS, и CIFS тоже получили такую функциональность. Но по описанию я не очень понял, относится ли это, к примеру, к RAW дискам, расположенным в директории. Из описания вроде бы да (Directory, NFS, and CIFS storages also gain additional support for snapshots as volume chains), но я не понимаю, как это технически реализовано. Надо будет на практике проверять. Вроде бы автоматически создаётся qcow2 файл для накопления изменений относительно базового диска.
◽️Добавлена функциональность SDN Fabric для построения отказоустойчивых управляемых и динамически маршрутизируемых сетей. У меня таких вообще нет, так что попробовать не придётся. Это в основном актуально для больших кластеров.
◽️Дополнительные графики с метриками. Будет полезно. Я частенько их смотрю для беглой оценки работы VM.
◽️Новый мобильный веб интерфейс. Лично я им вообще не пользуюсь. Заходил очень редко в исключительных ситуациях. Не знаю, зачем он нужен. Изредка можно и версию для ПК открыть.
Из основного это всё. Как я понимаю, триггером для релиза был переход на Debian 13, поэтому непосредственно в функциональности изменений немного.
📌 Ключевые обновления Proxmox BS:
🔥Поддержка S3-совместимых хранилищ. Этого реально не хватало. Подобные хранилища очень популярны и относительно дёшевы. Теперь можно спокойно брать дедики с небольшими локальными дисками и подключать более дешёвые S3 хранилища.
◽️Автоматический запуск синхронизации при подключении съёмного хранилища. Можно руками подключить внешний диск или подключить скриптами и бэкап на него будет автоматически синхронизирован. Потом его можно отмонтировать.
◽️Много мелких исправлений в интерфейсе, в уведомлениях, в очистке старых данных и некоторых других моментах.
Я наверное первые обновления сделаю, когда выйдут версии 9.1 и 4.1.
#proxmox
Расскажу про своё отношение к обновлению гипервизоров. Если рядом нет подменного сервера, на который можно быстро восстановить работу виртуальных машин, то я его не обновляю без веских оснований. Процесс этот откладываю на максимально комфортное время, когда это можно сделать. Обычно какие-то длинные праздники, типа майских или новогодних. То же самое для кластера. Обновлять надо очень аккуратно и понимать, что ты будешь делать, если он вдруг не переживёт обновление. Уронить прод от неаккуратного обновления гораздо проще, чем получить проблемы от каких-то уязвимостей, которых во-первых, не так много, чтобы это было опасно в закрытом контуре, во-вторых, обновления приходят регулярно и если постоянно обновляться по мере их выхода, то частота этого процесса сама по себе по теории вероятности принесёт рано или поздно проблемы.
Соответственно, вы либо держите тестовый контур, там всё проверяете и регулярно обновляетесь, либо изыскиваете какие-то другие подходы к этому процессу, более безопасные и растянутые во времени. Опять же, если нет чего-то срочного и критичного. Для Proxmox вообще такого не припоминаю. В интернет они у меня никогда не смотрят, и доступ к ним ограничен. Ещё раз подчеркну, что этот подход используется только для гипервизоров. Не для виртуальных машин с рабочей нагрузкой. Их можно относительно безопасно обновлять, так как масштаб бедствия несоизмерим, если что-то пойдёт не так.
📌Ключевые обновления Proxmox VE:
🔥Обычные LVM тома, не Thin, теперь поддерживают снэпшоты. У меня это самый популярный формат хранения. Из-за того, что он не поддерживал снепшоты, иногда приходилось использовать qcow2 диски, но они не очень удобны из-за ряда особенностей. В описании указано, что хранилища типа Directory, NFS, и CIFS тоже получили такую функциональность. Но по описанию я не очень понял, относится ли это, к примеру, к RAW дискам, расположенным в директории. Из описания вроде бы да (Directory, NFS, and CIFS storages also gain additional support for snapshots as volume chains), но я не понимаю, как это технически реализовано. Надо будет на практике проверять. Вроде бы автоматически создаётся qcow2 файл для накопления изменений относительно базового диска.
◽️Добавлена функциональность SDN Fabric для построения отказоустойчивых управляемых и динамически маршрутизируемых сетей. У меня таких вообще нет, так что попробовать не придётся. Это в основном актуально для больших кластеров.
◽️Дополнительные графики с метриками. Будет полезно. Я частенько их смотрю для беглой оценки работы VM.
◽️Новый мобильный веб интерфейс. Лично я им вообще не пользуюсь. Заходил очень редко в исключительных ситуациях. Не знаю, зачем он нужен. Изредка можно и версию для ПК открыть.
Из основного это всё. Как я понимаю, триггером для релиза был переход на Debian 13, поэтому непосредственно в функциональности изменений немного.
📌 Ключевые обновления Proxmox BS:
🔥Поддержка S3-совместимых хранилищ. Этого реально не хватало. Подобные хранилища очень популярны и относительно дёшевы. Теперь можно спокойно брать дедики с небольшими локальными дисками и подключать более дешёвые S3 хранилища.
◽️Автоматический запуск синхронизации при подключении съёмного хранилища. Можно руками подключить внешний диск или подключить скриптами и бэкап на него будет автоматически синхронизирован. Потом его можно отмонтировать.
◽️Много мелких исправлений в интерфейсе, в уведомлениях, в очистке старых данных и некоторых других моментах.
Я наверное первые обновления сделаю, когда выйдут версии 9.1 и 4.1.
#proxmox
6👍108👎2
Главные по контейнеризации в России приглашают на второй митап Deckhouse User Community.
21 августа | Москва
Приходите, если работаете с Kubernetes или планируете начать. Разберём три практических кейса:
→ как DKP управляет узлами кластера — от создания до вывода из кластера;
→ как построить платформу обучения на Community Edition быстрее ванильного Kubernetes;
→ как автоматизировать контроль архитектуры с помощью фитнес-функций.
Будет полезно инженерам эксплуатации, платформенным разработчикам и всем, кто хочет прокачать навыки работы с современными подходами в DevOps.
Только офлайн. Пицца и нетворкинг в программе. Регистрируйтесь!
21 августа | Москва
Приходите, если работаете с Kubernetes или планируете начать. Разберём три практических кейса:
→ как DKP управляет узлами кластера — от создания до вывода из кластера;
→ как построить платформу обучения на Community Edition быстрее ванильного Kubernetes;
→ как автоматизировать контроль архитектуры с помощью фитнес-функций.
Будет полезно инженерам эксплуатации, платформенным разработчикам и всем, кто хочет прокачать навыки работы с современными подходами в DevOps.
Только офлайн. Пицца и нетворкинг в программе. Регистрируйтесь!
👍17👎9
Небольшая информация из практики эксплуатации почтового сервера, с которой столкнулся впервые, и был немного удивлён. Получил от сервера Postfix уведомление:
This is the mail system at host mail.example.com.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<[email protected]>: mail for clientdomain.com loops back to myself
Вроде всё ясно, но ничего не понятно. Сервер ответил, что не может отправить письмо на домен clientdomain.com, потому что это отправка самому себе. С чего бы вдруг? Домен clientdomain.com к почтовому серверу не имеет никакого отношения.
Я сначала подумал, что возможно какой-то глюк с самим доменом. Может написан с каким-то спецсимволом и сервер так на него отреагировал. Но не похоже. Вообще, сервер Postfix очень информативен в плане логов. Люблю его за это. По логам всегда можно разобраться в проблемной ситуации. Обычно там всё по делу и сразу понимаешь, куда копать, что искать. Да и поисковики быстро помогают. По этому серверу накоплена огромная база знаний по всему интернету.
Вечерком сел и решил спокойно разобраться. Было интересно, в чём реально проблема. Начал с самого простого и тут же получил ответ:
Сразу догадался, в чём дело. Зашёл на домен по HTTP и увидел информацию о том, что срок регистрации домена истёк.
Как оказалось, этот домен принадлежит регистратору Nic. И у него закончилось делегирование. Nic почему-то для таких доменов прописывает свой MX сервер в DNS - nomail.nic.ru и назначает ему адрес 127.0.0.1. Вот мой Postfix и пытался отправить письмо самому себе через 127.0.0.1, но в своих настройках не имел этого домена. Ошибка получилась вполне логичной. А вот поведение Nic - не совсем. Первый раз столкнулся, что разделегированный домен резолвят на 127.0.0.1.
Хорошая история для какого-нибудь тестового задания по теме почтовых серверов. Изначально я смотрел лог почтового сервера во время отправки, смотрел выборку по ID письма и там было непонятно, почему письмо для этого домена попадает на loops back to myself.
#mailserver
This is the mail system at host mail.example.com.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<[email protected]>: mail for clientdomain.com loops back to myself
Вроде всё ясно, но ничего не понятно. Сервер ответил, что не может отправить письмо на домен clientdomain.com, потому что это отправка самому себе. С чего бы вдруг? Домен clientdomain.com к почтовому серверу не имеет никакого отношения.
Я сначала подумал, что возможно какой-то глюк с самим доменом. Может написан с каким-то спецсимволом и сервер так на него отреагировал. Но не похоже. Вообще, сервер Postfix очень информативен в плане логов. Люблю его за это. По логам всегда можно разобраться в проблемной ситуации. Обычно там всё по делу и сразу понимаешь, куда копать, что искать. Да и поисковики быстро помогают. По этому серверу накоплена огромная база знаний по всему интернету.
Вечерком сел и решил спокойно разобраться. Было интересно, в чём реально проблема. Начал с самого простого и тут же получил ответ:
# dig clientdomain.com MXnomail.nic.ru. 164 IN A 127.0.0.1Сразу догадался, в чём дело. Зашёл на домен по HTTP и увидел информацию о том, что срок регистрации домена истёк.
Как оказалось, этот домен принадлежит регистратору Nic. И у него закончилось делегирование. Nic почему-то для таких доменов прописывает свой MX сервер в DNS - nomail.nic.ru и назначает ему адрес 127.0.0.1. Вот мой Postfix и пытался отправить письмо самому себе через 127.0.0.1, но в своих настройках не имел этого домена. Ошибка получилась вполне логичной. А вот поведение Nic - не совсем. Первый раз столкнулся, что разделегированный домен резолвят на 127.0.0.1.
Хорошая история для какого-нибудь тестового задания по теме почтовых серверов. Изначально я смотрел лог почтового сервера во время отправки, смотрел выборку по ID письма и там было непонятно, почему письмо для этого домена попадает на loops back to myself.
#mailserver
2👍109👎2