В комментариях к статье читатели посоветовали еще один конфигуратор для PostgreSQL.
Но это не просто конфигуратор. А разработка отечественных ребят и заточенный именно под 1С (выбираем Нагрузка базы данных - ERP1C).
Внимания однозначно заслуживает, кроме того позволяет выполнять не только базовую, но и гораздо более тонкую настройку.
https://tantorlabs.ru/pgconfigurator
Но это не просто конфигуратор. А разработка отечественных ребят и заточенный именно под 1С (выбираем Нагрузка базы данных - ERP1C).
Внимания однозначно заслуживает, кроме того позволяет выполнять не только базовую, но и гораздо более тонкую настройку.
https://tantorlabs.ru/pgconfigurator
👍34❤11
Сегодня у нас в Белгороде случилась страшная трагедия. BMW X7 в самом центре Белгорода протаранил карету Скорой помощи. Две девушки фельдшера погибли на месте, водитель крайне тяжелый в реанимации.
Я не прошу ни о чем, но кто может - помогите посильно семьям погибших, реквизиты будут в репосте ниже. Кто что может, посильно. Они за небольшую зарплату были фельдшерами скорой и ехали на очередной вызов.
Я не прошу ни о чем, но кто может - помогите посильно семьям погибших, реквизиты будут в репосте ниже. Кто что может, посильно. Они за небольшую зарплату были фельдшерами скорой и ехали на очередной вызов.
😢67🙏9👍1😁1
Forwarded from Белгород №1
Публикуем номера, по которым можно помочь финансово семьям погибших в аварии фельдшеров.
Семье Марины Паровышник:
89803233905, Иван Александрович П., сын погибшей (Т-Банк, ВТБ)
Семье Ольги Любимовой:
89163945642, Анна Сергеевна Л., сестра погибшей (Сбер)
Фото с места стихийного мемориала: «Белгородка».
❤️ Подпишись на «Белгород №1»
Семье Марины Паровышник:
89803233905, Иван Александрович П., сын погибшей (Т-Банк, ВТБ)
Семье Ольги Любимовой:
89163945642, Анна Сергеевна Л., сестра погибшей (Сбер)
Фото с места стихийного мемориала: «Белгородка».
Please open Telegram to view this post
VIEW IN TELEGRAM
😢52🤯3
Неочевидное - невероятное
Работая с определенным оборудованием накапливается опыт и определённые практики. Некоторые действуют на подсознательном уровне.
Так в Mikrotik если мы что-то изменили - оно становится синим. Но не всегда и не везде.
Откроем брандмауэр и создадим там правило пустышку, ну, скажем, такое.
Но не тут-то было, вывод правил в терминал покажет нам:
Поэтому всегда контролируйте через экспорт конфигурации внесенные изменения, особенно если вас занесло в такие места RouterOS, где вы еще не были, даже если заходили вы просто посмотреть.
Работая с определенным оборудованием накапливается опыт и определённые практики. Некоторые действуют на подсознательном уровне.
Так в Mikrotik если мы что-то изменили - оно становится синим. Но не всегда и не везде.
Откроем брандмауэр и создадим там правило пустышку, ну, скажем, такое.
0 chain=forward action=accept log=no log-prefix=""
Теперь откроем его в Winboх и полазим на закладке Extra, ничего не трогаем, просто смотрим. Как видим ничего не посинело, спокойно уходим и жмем OK.Но не тут-то было, вывод правил в терминал покажет нам:
0 chain=forward action=accept psd=21,3s,3,1 limit=1,5:packet dst-limit=1,5,dst-address/1m40s time=0s-1d,sun,mon,tue,wed,thu,fri,sat log=no
log-prefix="
Внезапно! Поэтому всегда контролируйте через экспорт конфигурации внесенные изменения, особенно если вас занесло в такие места RouterOS, где вы еще не были, даже если заходили вы просто посмотреть.
👍41😁1
Во всем виноват IPsec, однозначно!
А если серьезно, то поднимая любую технологию, пусть даже по подробной пошаговой инструкции всегда надо хоть немного вникать в то, что это такое и как работает.
Чтобы потом не было подобных вопросов. Хотя это как раз классика: я поднял IPsec и где мои маршруты? Равно как и почему у меня из-за NAT работает ровно один клиент.
Тем более что подобные вещи достаточно легко гуглятся. Но увы, чаще всего сначала делают, потом ходят по граблям и только потом начинают читать.
Не надо так. IKEv2 - отличный инструмент для удаленного доступа, тем более он уже есть в каждом клиенте, но для соединения сетей выберите что-то другое.
А если серьезно, то поднимая любую технологию, пусть даже по подробной пошаговой инструкции всегда надо хоть немного вникать в то, что это такое и как работает.
Чтобы потом не было подобных вопросов. Хотя это как раз классика: я поднял IPsec и где мои маршруты? Равно как и почему у меня из-за NAT работает ровно один клиент.
Тем более что подобные вещи достаточно легко гуглятся. Но увы, чаще всего сначала делают, потом ходят по граблям и только потом начинают читать.
Не надо так. IKEv2 - отличный инструмент для удаленного доступа, тем более он уже есть в каждом клиенте, но для соединения сетей выберите что-то другое.
👍21😁2🤔1😱1
Про IPsec для самых маленьких
Набор протоколов IPsec широко используется для защиты сетевых соединений, но он же вызывает наибольшее количество затруднений у начинающих пользователей (и не только).
Очевидный плюс IPsec – высокий уровень надежности и защиты, а дальше пошли сплошные минусы. Как следует из названия IPsec работает на сетевом уровне и использует протокол IP, что делает его универсальным и прозрачным для любых вышестоящих протоколов.
При этом IPsec не плодит никаких лишних сущностей: новых соединений, интерфейсов и т.д. и т.п. Т.е. вы как работали с IP, так и продолжаете работать, а IPsec тихо и незаметно делает свое дело.
Это и обуславливает его широкое распространение, вам не нужно думать о поддержке IPsec со стороны своего сетевого приложения, достаточно того, что оно может работать с IP. И это же является основной сложностью для работающих с ним администраторов.
Правила обработки трафика IPsec задаются политиками и основаны на адресах источника и назначения пакета. Никаких интерфейсов - только адреса, маршрутизация тоже не работает. Точнее она работает, но там, где должна работать, на принятие решения о том, будет зашифрован IP-пакет или нет она не влияет.
IPsec может работать в двух режимах – туннельном и транспортном. Начнем с транспортного, в этом случае шифруется только полезное содержимое IP -пакета, заголовки оставляются в неизменном виде.
Это удобно для защиты трафика между узлами, имеющими внешние IP-адреса, что позволяет шифровать только полезное содержимое и исключить дополнительные накладные расходы.
В туннельном режиме пакет шифруется полностью, со всеми заголовками и помещается внутрь нового пакета, который отправляется второй стороне, указанной в настройках IPsec соединения.
В данном случае IPsec работает как классический туннель с инкапсуляцией пакетов, но то, какие пакеты будут инкапсулированы определяется также политиками, а не маршрутизацией.
А далее такой пакет и неважно туннельный или транспортный режим там используется пойдет, как и любой другой по всем правилам брандмауэра и установленным маршрутам.
Здесь появляется очередная сложность – избежать дополнительной обработки такого пакета брандмауэром и особенно NAT, в противном случае изменятся его адреса источника / назначения, и он перестанет соответствовать политикам IPsec. Все это решаемо, но требует определенных знаний и понимания.
Ну и, наконец, работать IPsec может совершенно на разных уровнях. Например, часто мы говорим, что подняли туннель GRE over IPsec, а кто-то может поднять IPsec over GRE. Казалось бы, какая разница, все равно у нас есть зашифрованный туннель. Но разница есть, и она огромная.
GRE over IPsec обозначает что мы поднимаем GRE-туннель не предусматривающий никакого шифрования поверх уже установленного IPsec соединения между узлами.
Что это значит? А то, что между узлами А и Б при помощи IPsec будет защищен любой IP-трафик, а не только GRE. Вы можете гонять там что угодно и все это будет также защищено при помощи IPsec.
А если мы поднимем IPsec over GRE, то в этом случае мы создаем между узлами А и Б незашифрованный туннель, но все что ходит в этом туннеле и только шифруется с помощью IPsec. Только то, что в туннеле, а не весь трафик между внешними узлами.
Причем право на жизнь имеют обе модели, все зависит от задач, но разница между ними более чем существенна и без понимания таких тонкостей можно наделать откровенно странных конструкций или недоумевать, почему сеть работает не так, как «задумано».
Поэтому перед тем, как бездумно настраивать IPsec уделите время на хотя бы обзорное знакомство с этим набором протоколов, чтобы вы хотя бы на базовом уровне имели представление как это взаимодействует между собой и почему работает именно так, а не иначе.
Набор протоколов IPsec широко используется для защиты сетевых соединений, но он же вызывает наибольшее количество затруднений у начинающих пользователей (и не только).
Очевидный плюс IPsec – высокий уровень надежности и защиты, а дальше пошли сплошные минусы. Как следует из названия IPsec работает на сетевом уровне и использует протокол IP, что делает его универсальным и прозрачным для любых вышестоящих протоколов.
При этом IPsec не плодит никаких лишних сущностей: новых соединений, интерфейсов и т.д. и т.п. Т.е. вы как работали с IP, так и продолжаете работать, а IPsec тихо и незаметно делает свое дело.
Это и обуславливает его широкое распространение, вам не нужно думать о поддержке IPsec со стороны своего сетевого приложения, достаточно того, что оно может работать с IP. И это же является основной сложностью для работающих с ним администраторов.
Правила обработки трафика IPsec задаются политиками и основаны на адресах источника и назначения пакета. Никаких интерфейсов - только адреса, маршрутизация тоже не работает. Точнее она работает, но там, где должна работать, на принятие решения о том, будет зашифрован IP-пакет или нет она не влияет.
IPsec может работать в двух режимах – туннельном и транспортном. Начнем с транспортного, в этом случае шифруется только полезное содержимое IP -пакета, заголовки оставляются в неизменном виде.
Это удобно для защиты трафика между узлами, имеющими внешние IP-адреса, что позволяет шифровать только полезное содержимое и исключить дополнительные накладные расходы.
В туннельном режиме пакет шифруется полностью, со всеми заголовками и помещается внутрь нового пакета, который отправляется второй стороне, указанной в настройках IPsec соединения.
В данном случае IPsec работает как классический туннель с инкапсуляцией пакетов, но то, какие пакеты будут инкапсулированы определяется также политиками, а не маршрутизацией.
А далее такой пакет и неважно туннельный или транспортный режим там используется пойдет, как и любой другой по всем правилам брандмауэра и установленным маршрутам.
Здесь появляется очередная сложность – избежать дополнительной обработки такого пакета брандмауэром и особенно NAT, в противном случае изменятся его адреса источника / назначения, и он перестанет соответствовать политикам IPsec. Все это решаемо, но требует определенных знаний и понимания.
Ну и, наконец, работать IPsec может совершенно на разных уровнях. Например, часто мы говорим, что подняли туннель GRE over IPsec, а кто-то может поднять IPsec over GRE. Казалось бы, какая разница, все равно у нас есть зашифрованный туннель. Но разница есть, и она огромная.
GRE over IPsec обозначает что мы поднимаем GRE-туннель не предусматривающий никакого шифрования поверх уже установленного IPsec соединения между узлами.
Что это значит? А то, что между узлами А и Б при помощи IPsec будет защищен любой IP-трафик, а не только GRE. Вы можете гонять там что угодно и все это будет также защищено при помощи IPsec.
А если мы поднимем IPsec over GRE, то в этом случае мы создаем между узлами А и Б незашифрованный туннель, но все что ходит в этом туннеле и только шифруется с помощью IPsec. Только то, что в туннеле, а не весь трафик между внешними узлами.
Причем право на жизнь имеют обе модели, все зависит от задач, но разница между ними более чем существенна и без понимания таких тонкостей можно наделать откровенно странных конструкций или недоумевать, почему сеть работает не так, как «задумано».
Поэтому перед тем, как бездумно настраивать IPsec уделите время на хотя бы обзорное знакомство с этим набором протоколов, чтобы вы хотя бы на базовом уровне имели представление как это взаимодействует между собой и почему работает именно так, а не иначе.
👍69❤1
❓ Хотите научиться запускать сайты на Linux с нуля?
На открытом уроке «Запускаем CMS Wordpress на Ubuntu 24.04» вы освоите настройку полного окружения для работы сайта.
💪 Что вы узнаете:
— Как установить и настроить веб-сервер Angie, PHP-FPM и MySQL.
— Как развернуть WordPress на чистой системе Ubuntu 24.04.
— Как создать полнофункциональный сайт с минимальными ресурсами.
⭐ Спикер Николай Лавлинский — технический директор в Метод Лаб, PhD Economic Science, опытный руководитель разработки и преподаватель.
⏰ Встречаемся 12 февраля в 19:00 мск. Урок проходит в преддверии старта курса «Administrator Linux. Basic», а участники получат скидку на обучение.
👉 Сделайте первый шаг к профессии администратора Linux или запустите свой веб-проект: https://otus.pw/cYLN/?erid=2W5zFJhhwcU
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
На открытом уроке «Запускаем CMS Wordpress на Ubuntu 24.04» вы освоите настройку полного окружения для работы сайта.
💪 Что вы узнаете:
— Как установить и настроить веб-сервер Angie, PHP-FPM и MySQL.
— Как развернуть WordPress на чистой системе Ubuntu 24.04.
— Как создать полнофункциональный сайт с минимальными ресурсами.
⭐ Спикер Николай Лавлинский — технический директор в Метод Лаб, PhD Economic Science, опытный руководитель разработки и преподаватель.
⏰ Встречаемся 12 февраля в 19:00 мск. Урок проходит в преддверии старта курса «Administrator Linux. Basic», а участники получат скидку на обучение.
👉 Сделайте первый шаг к профессии администратора Linux или запустите свой веб-проект: https://otus.pw/cYLN/?erid=2W5zFJhhwcU
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
🤡6🤮4❤2
Б/у диски Seagate массово продаются под видом новых.
Еще с января не утихает скандал с массовой продажей в розницу б/у серверных дисков Seagate под видом новых.
Первыми о таких случаях сообщили продавцы из Германии, а на настоящий момент поддельная продукция была обнаружена и в других странах Европы, Австралии, Тайланде, Японии.
Диски имеют сброшенный SMART, что создает иллюзию нового, но если сделать запрос к счетчику продолжительности использования FARM, то будет виден реальный пробег диска, который составляет от 15 000 до 50 000 часов.
Продавцы уверяют, что не имели понятия о том, что торгуют поддельными дисками. Компания Seagate также утверждает о своей непричастности к произошедшему и обещала начать собственное расследование.
Его предварительные результаты ведут к китайским майнинговым фермам, которые добывали монету Chia. Теперь, после падения рентабельности многие фермы закрылись и на рынок выплеснулось большое количество бывших в интенсивном употреблении дисков.
Дальше кто-то из ушлых китайских товарищей подсуетился, а кто-то из дистрибьюторов польстился на низкую цену не проверив происхождение товара. Теперь же, когда подлог вскрылся, под ударом оказались и продавцы, и производитель.
Также стоит ожидать появления такой продукции как на китайских площадках, так и на вторичном рынке, в т.ч. и в мелкой рознице, которая может сама не знать, что продает.
Поэтому крайне внимательно относитесь к покупке такой продукции и обязательно проверяйте реальную наработку, это можно сделать официальной утилитой с сайта производителя.
Еще с января не утихает скандал с массовой продажей в розницу б/у серверных дисков Seagate под видом новых.
Первыми о таких случаях сообщили продавцы из Германии, а на настоящий момент поддельная продукция была обнаружена и в других странах Европы, Австралии, Тайланде, Японии.
Диски имеют сброшенный SMART, что создает иллюзию нового, но если сделать запрос к счетчику продолжительности использования FARM, то будет виден реальный пробег диска, который составляет от 15 000 до 50 000 часов.
Продавцы уверяют, что не имели понятия о том, что торгуют поддельными дисками. Компания Seagate также утверждает о своей непричастности к произошедшему и обещала начать собственное расследование.
Его предварительные результаты ведут к китайским майнинговым фермам, которые добывали монету Chia. Теперь, после падения рентабельности многие фермы закрылись и на рынок выплеснулось большое количество бывших в интенсивном употреблении дисков.
Дальше кто-то из ушлых китайских товарищей подсуетился, а кто-то из дистрибьюторов польстился на низкую цену не проверив происхождение товара. Теперь же, когда подлог вскрылся, под ударом оказались и продавцы, и производитель.
Также стоит ожидать появления такой продукции как на китайских площадках, так и на вторичном рынке, в т.ч. и в мелкой рознице, которая может сама не знать, что продает.
Поэтому крайне внимательно относитесь к покупке такой продукции и обязательно проверяйте реальную наработку, это можно сделать официальной утилитой с сайта производителя.
👌25👍14❤1😱1
Lithnet Password Protection for Active Directory (LPP)
Lithnet Password Protection for Active Directory (LPP) – приложение с открытым исходным кодом, который добавляет в Active Directory дополнительный фильтр паролей, который позволяет контролировать соответствие паролей пользователей расширенным требованиям.
Для чего это нужно? Стандартная политика паролей Windows позволяет задавать лишь общие требования к паролям и не позволяет выполнять их дополнительную проверку, например, политике будет полностью соответствовать такой пароль: Pa$$word1
Это позволяет пользователям обходить формальные требования и использовать фактически слабые пароли. LPP позволяет решить эту проблему используя внутреннюю базу запрещенных слов, при этом будут учитываться все типовые замены и обфускации.
Например, если мы добавим в базу слово password то программа заблокирует такие варианты как Pa$$word1, P@ssw0rd, pa55word! Или password123456!'
Для тех, кто хочет большего, можно подключить внешнюю базу Have I Been Pwned (HIBP), которая содержит скомпрометированные пароли, для этого вам понадобится около 8 ГБ свободного места.
После чего вы можете проверить уже имеющиеся пароли на их компрометацию, для этой проверки не требуется интернет и хеш пароля не покидает контроллер домена. Для параноиков поясняем – вся работа со скачанной базой производится сугубо локально.
Любите использовать регулярные выражения? Здесь тоже есть широкое поле, укажите регулярки под которые должен или наоборот не должен попадать пароль.
Также вы можете установить разные требования для паролей разной длинны, скажем требовать для коротких паролей обязательного наличия специальных символов, а для более длинных достаточно будет только цифр и букв.
Можно также использовать бальную систему, когда за определенные символы и комбинации присваивается некоторое количество баллов и пользователь должен получить не менее некоторого минимального значения.
Продукт полностью интегрирован с PowerShell и удобно управляется с его помощью, а также поставляется с набором собственных групповых политик, позволяющих гибко применять его возможности в домене.
И все это, как мы уже говорили – бесплатно, по лицензии MIT.
✅ Страница проекта: https://github.com/lithnet/ad-password-protection
Lithnet Password Protection for Active Directory (LPP) – приложение с открытым исходным кодом, который добавляет в Active Directory дополнительный фильтр паролей, который позволяет контролировать соответствие паролей пользователей расширенным требованиям.
Для чего это нужно? Стандартная политика паролей Windows позволяет задавать лишь общие требования к паролям и не позволяет выполнять их дополнительную проверку, например, политике будет полностью соответствовать такой пароль: Pa$$word1
Это позволяет пользователям обходить формальные требования и использовать фактически слабые пароли. LPP позволяет решить эту проблему используя внутреннюю базу запрещенных слов, при этом будут учитываться все типовые замены и обфускации.
Например, если мы добавим в базу слово password то программа заблокирует такие варианты как Pa$$word1, P@ssw0rd, pa55word! Или password123456!'
Для тех, кто хочет большего, можно подключить внешнюю базу Have I Been Pwned (HIBP), которая содержит скомпрометированные пароли, для этого вам понадобится около 8 ГБ свободного места.
После чего вы можете проверить уже имеющиеся пароли на их компрометацию, для этой проверки не требуется интернет и хеш пароля не покидает контроллер домена. Для параноиков поясняем – вся работа со скачанной базой производится сугубо локально.
Любите использовать регулярные выражения? Здесь тоже есть широкое поле, укажите регулярки под которые должен или наоборот не должен попадать пароль.
Также вы можете установить разные требования для паролей разной длинны, скажем требовать для коротких паролей обязательного наличия специальных символов, а для более длинных достаточно будет только цифр и букв.
Можно также использовать бальную систему, когда за определенные символы и комбинации присваивается некоторое количество баллов и пользователь должен получить не менее некоторого минимального значения.
Продукт полностью интегрирован с PowerShell и удобно управляется с его помощью, а также поставляется с набором собственных групповых политик, позволяющих гибко применять его возможности в домене.
И все это, как мы уже говорили – бесплатно, по лицензии MIT.
✅ Страница проекта: https://github.com/lithnet/ad-password-protection
👍54🔥7
❗️Освойте новые инструменты DevOps и администрирования со скидкой до 15 000₽
Хотите вырасти как специалист и работать на более сложных проектах?
▶️Собрали курсы, которые охватывают весь спектр необходимых знаний и инструментов для профессионального роста 一 от контейнеризации с Docker и оркестрации с Kubernetes, до автоматизации CI/CD и управления облачной инфраструктурой.
▶️Вы научитесь мониторить и логировать системы, строить надежные CI/CD пайплайны, предоставлять и поддерживать вычислительную инфраструктуру с помощью кода, балансировать нагрузку БД и многое другое.
🎁А чтобы учиться было еще приятнее, всем инженерам, администраторам и DevOps дарим промокод FEB25 на скидку 15000₽
*ввести его можно в окне оплаты, оно откроется после заполнения формы контактов
Переходите по ссылке и расширяйте свой стек технологий, чтобы с легкостью управлять сложными проектами и стать незаменимым в любой IT-команде.
#реклама
О рекламодателе
Хотите вырасти как специалист и работать на более сложных проектах?
▶️Собрали курсы, которые охватывают весь спектр необходимых знаний и инструментов для профессионального роста 一 от контейнеризации с Docker и оркестрации с Kubernetes, до автоматизации CI/CD и управления облачной инфраструктурой.
▶️Вы научитесь мониторить и логировать системы, строить надежные CI/CD пайплайны, предоставлять и поддерживать вычислительную инфраструктуру с помощью кода, балансировать нагрузку БД и многое другое.
🎁А чтобы учиться было еще приятнее, всем инженерам, администраторам и DevOps дарим промокод FEB25 на скидку 15000₽
*ввести его можно в окне оплаты, оно откроется после заполнения формы контактов
Переходите по ссылке и расширяйте свой стек технологий, чтобы с легкостью управлять сложными проектами и стать незаменимым в любой IT-команде.
#реклама
О рекламодателе
😢1
Резервные копии Active Direcitory
Вынесенная в заголовок тема давно служит предметом споров, в частности многих смущают противоречивые, я бы даже сказал – взаимоисключающие рекомендации, которые звучат примерно так: резервные копии контроллеров домена делать надо, но восстанавливать их из резервных копий не следует!
В чем причина? А причина в USN Rollback – главной страшилке системных администраторов былых времён. Сейчас получить USN Rollback все так же можно, но никаких особых последствий у вас не будет.
Чтобы понять, что такое USN Rollback нужно немного углубиться в работу репликации базы данных AD. Для того, чтобы не гонять каждый раз по сети всю базу контроллеры передают только измененные объекты.
Каждое изменение метаданных AD снабжается специальным идентификатором контроллера домена - Invocation ID - и последовательным номером – USN.
Другие контроллеры, выполнив репликацию, запоминают этот идентификатор и USN, после чего при следующей репликации будут запрашивать объекты с USN указанного номера.
При USN Rollback у контролера уменьшается текущий максимальный номер USN, и он начинает создавать изменения, которые никогда не будут реплицированы, чем переводит базу AD в рассогласованное состояние.
Чем это чревато? Различными тяжелыми глюками и ошибками работы AD, вплоть до ситуации полного хаоса в сети, когда пользователи аутентифицируются через раз, политики работают не так как следует и т.д. и т.п.
Начиная с 2012 Microsoft добавила ряд функций препятствующих такому развитию событий, в частности обнаружение USN Rollback, когда контроллер перед началом репликации запрашивает сохраненные USN с других контролеров в сети.
Если полученное значение превышает собственный максимальный USN, то на контроллере полностью блокируется репликация, а службы Active Directory переводятся в приостановленное состояние.
Но если у контроллера долгое время не было связи с AD и на нем активно вносились изменения, то может оказаться, что максимальный USN контроллера окажется выше и обнаружения USN Rollback не произойдет, после чего мы снова получим весь спектр чудес в одном флаконе.
Ситуацию осложняет еще и то, что современные администраторы скорее всего никогда не сталкивались с этой бедой, не знают ее симптомов и будут искать не там, где нужно, а там, где светлее.
Что касается восстановления контроллера через родной режим службы восстановления каталогов (вам понадобится резервная копия, сделанная службой Windows Server Backup), то в конце восстановления контроллеру меняют Invocation ID, что заставляет остальные контроллеры считать его новым контроллером в AD и начать репликацию с ним «с чистого листа».
Поэтому мы не видим насущной необходимости восстанавливать сбойный КД, в лучшем случае вы потратите на восстановление столько же времени, сколько на настройку нового КД, а то и гораздо больше, так как настройка КД – задача привычная, а восстановление – новая и не совсем понятная.
В худшем, если бекап был сделан программой не умеющей восстанавливать KД (а именно менять Invocation ID), то вы потеряете контроллер и вам все равно придется настраивать его заново.
Так для чего же нужна резервная копия контроллеров AD? А нужна она на случай, если вы серьезно нарушите текущую структуру AD или внесете туда несовместимые с нормальной работой изменения.
В этом случае вам придется понизить все контроллеры кроме одного, восстановить его из резервной копии, а затем снова добавить нужное количество контроллеров.
Но мы надеемся, что данной ситуации у вас не возникнет.
Вынесенная в заголовок тема давно служит предметом споров, в частности многих смущают противоречивые, я бы даже сказал – взаимоисключающие рекомендации, которые звучат примерно так: резервные копии контроллеров домена делать надо, но восстанавливать их из резервных копий не следует!
В чем причина? А причина в USN Rollback – главной страшилке системных администраторов былых времён. Сейчас получить USN Rollback все так же можно, но никаких особых последствий у вас не будет.
Чтобы понять, что такое USN Rollback нужно немного углубиться в работу репликации базы данных AD. Для того, чтобы не гонять каждый раз по сети всю базу контроллеры передают только измененные объекты.
Каждое изменение метаданных AD снабжается специальным идентификатором контроллера домена - Invocation ID - и последовательным номером – USN.
Другие контроллеры, выполнив репликацию, запоминают этот идентификатор и USN, после чего при следующей репликации будут запрашивать объекты с USN указанного номера.
При USN Rollback у контролера уменьшается текущий максимальный номер USN, и он начинает создавать изменения, которые никогда не будут реплицированы, чем переводит базу AD в рассогласованное состояние.
Чем это чревато? Различными тяжелыми глюками и ошибками работы AD, вплоть до ситуации полного хаоса в сети, когда пользователи аутентифицируются через раз, политики работают не так как следует и т.д. и т.п.
Начиная с 2012 Microsoft добавила ряд функций препятствующих такому развитию событий, в частности обнаружение USN Rollback, когда контроллер перед началом репликации запрашивает сохраненные USN с других контролеров в сети.
Если полученное значение превышает собственный максимальный USN, то на контроллере полностью блокируется репликация, а службы Active Directory переводятся в приостановленное состояние.
Но если у контроллера долгое время не было связи с AD и на нем активно вносились изменения, то может оказаться, что максимальный USN контроллера окажется выше и обнаружения USN Rollback не произойдет, после чего мы снова получим весь спектр чудес в одном флаконе.
Ситуацию осложняет еще и то, что современные администраторы скорее всего никогда не сталкивались с этой бедой, не знают ее симптомов и будут искать не там, где нужно, а там, где светлее.
Что касается восстановления контроллера через родной режим службы восстановления каталогов (вам понадобится резервная копия, сделанная службой Windows Server Backup), то в конце восстановления контроллеру меняют Invocation ID, что заставляет остальные контроллеры считать его новым контроллером в AD и начать репликацию с ним «с чистого листа».
Поэтому мы не видим насущной необходимости восстанавливать сбойный КД, в лучшем случае вы потратите на восстановление столько же времени, сколько на настройку нового КД, а то и гораздо больше, так как настройка КД – задача привычная, а восстановление – новая и не совсем понятная.
В худшем, если бекап был сделан программой не умеющей восстанавливать KД (а именно менять Invocation ID), то вы потеряете контроллер и вам все равно придется настраивать его заново.
Так для чего же нужна резервная копия контроллеров AD? А нужна она на случай, если вы серьезно нарушите текущую структуру AD или внесете туда несовместимые с нормальной работой изменения.
В этом случае вам придется понизить все контроллеры кроме одного, восстановить его из резервной копии, а затем снова добавить нужное количество контроллеров.
Но мы надеемся, что данной ситуации у вас не возникнет.
👍65
И снова нестареющая классика, ибо в очередной раз сегодня слушали про первичные контроллеры и прочую ересь.
Мифы и легенды Active Directory. Хозяева ролей FSMO
Active Directory, как и любая серьезная система с долгой историей успела приобрести свой фольклор, неотъемлемой частью которого являются мифы и легенды.
А одной из самых мифологизированных тем являются хозяева операций, они же роли FSMO, большее количество фантазий и суеверий существует разве что на тему равноправия контроллеров домена, но о них мы поговорим в другой раз.
Сегодня же попытаемся понять, что делают и чего не делают хозяева операций, для чего они вообще нужны и можно ли жить без них.
https://interface31.ru/tech_it/2022/06/mify-i-legendy-active-directory-hozyaeva-roley-fsmo.html
Мифы и легенды Active Directory. Хозяева ролей FSMO
Active Directory, как и любая серьезная система с долгой историей успела приобрести свой фольклор, неотъемлемой частью которого являются мифы и легенды.
А одной из самых мифологизированных тем являются хозяева операций, они же роли FSMO, большее количество фантазий и суеверий существует разве что на тему равноправия контроллеров домена, но о них мы поговорим в другой раз.
Сегодня же попытаемся понять, что делают и чего не делают хозяева операций, для чего они вообще нужны и можно ли жить без них.
https://interface31.ru/tech_it/2022/06/mify-i-legendy-active-directory-hozyaeva-roley-fsmo.html
👍35🌭3
Мифы и легенды Active Directory – откуда ноги растут
Как мы уже неоднократно говорили, администраторы Active Directory очень часто подвержены множественным заблуждениям, из которых уже сформировался устойчивый набор мифов и легенд.
Как водится, происхождение всего этого мифотворчества уходит своими корнями в далекие времена Windows NT, т.е. до 2000 года. Фактически уже выросло второе поколение специалистов, которые эту самую NT в глаза не видели, но тем не менее подвержены распространенным заблуждениям.
Поэтому предлагаем вам немного окунуться в историю и понять, чем являлся домен NT и что изменилось с приходом Active Directory.
Домен NT (NTDS) являлся реализаций службы каталогов от Microsoft доступный в серверной операционной системе Windows NT Server. И состоял из одного первичного контроллера домена – PDC (Primary Domain Controller) и неограниченного количества резервных – BDC (Backup Domain Controllers).
Именно на первичном контроллере хранилась основная база домена и все изменения в нее могли вноситься только на нем. Затем эта база реплицировалась на остальные резервные контроллеры, после чего они тоже могли начать обрабатывать клиентские запросы.
Если первичный контроллер выходил из строя, то домен фактически переходил в режим «только чтение». При его окончательной утере первичным можно было сделать один из резервных контроллеров.
Но это была достаточно непростая задача, учитывая, что выбор роли определялся только на этапе установки и его нельзя было изменить без переустановки системы. Т.е. мы не могли добавить уже существующему серверу роль контроллера или понизить его до рядового. Также сделав резервный контроллер основным, нельзя было снова изменить его роль на резервный.
Чтобы понять все сложности, с которыми сталкивались администраторы тех лет следует вспомнить, что виртуализация в те времена была чем-то из области научной фантастики и сервера были железными. И было их обычно не очень много, поэтому кроме роли контроллера они совмещали в себе еще множество функций и переустановка такого сервера была крайне непростой задачей.
А при появлении нового сервера приходилось крепко думать, будет ли он контроллером домена или нет. Так как изменить его назначение без переустановки было невозможно.
Также схема один PDC – много BDC имела серьезные проблемы с репликацией, особенно для удаленных филиалов с учетом скоростей и качества каналов связи того времени. При том, что удаленный филиал сам не мог внести необходимые данные в домен, так как для этого требовался первичный контроллер.
Поэтому с приходом Windows 2000 и Active Directory от данной схемы отказались, с этого момента все контроллеры домена стали равнозначны и каждый из них мог вносить изменения в базу домена, потом обмениваясь измененными данными. А для контроля целостности и уникальности данных были созданы хозяева операций.
Также теперь любой сервер мог стать контроллером домена или перестать им быть без переустановки, что значительно облегчило администрирование и планирование инфраструктуры.
Но несмотря на то, что Active Directory скоро разменяет четверть века многие коллеги все еще продолжают оперировать устаревшими терминами и понятиями системы, которую никогда в глаза не видели.
Как мы уже неоднократно говорили, администраторы Active Directory очень часто подвержены множественным заблуждениям, из которых уже сформировался устойчивый набор мифов и легенд.
Как водится, происхождение всего этого мифотворчества уходит своими корнями в далекие времена Windows NT, т.е. до 2000 года. Фактически уже выросло второе поколение специалистов, которые эту самую NT в глаза не видели, но тем не менее подвержены распространенным заблуждениям.
Поэтому предлагаем вам немного окунуться в историю и понять, чем являлся домен NT и что изменилось с приходом Active Directory.
Домен NT (NTDS) являлся реализаций службы каталогов от Microsoft доступный в серверной операционной системе Windows NT Server. И состоял из одного первичного контроллера домена – PDC (Primary Domain Controller) и неограниченного количества резервных – BDC (Backup Domain Controllers).
Именно на первичном контроллере хранилась основная база домена и все изменения в нее могли вноситься только на нем. Затем эта база реплицировалась на остальные резервные контроллеры, после чего они тоже могли начать обрабатывать клиентские запросы.
Если первичный контроллер выходил из строя, то домен фактически переходил в режим «только чтение». При его окончательной утере первичным можно было сделать один из резервных контроллеров.
Но это была достаточно непростая задача, учитывая, что выбор роли определялся только на этапе установки и его нельзя было изменить без переустановки системы. Т.е. мы не могли добавить уже существующему серверу роль контроллера или понизить его до рядового. Также сделав резервный контроллер основным, нельзя было снова изменить его роль на резервный.
Чтобы понять все сложности, с которыми сталкивались администраторы тех лет следует вспомнить, что виртуализация в те времена была чем-то из области научной фантастики и сервера были железными. И было их обычно не очень много, поэтому кроме роли контроллера они совмещали в себе еще множество функций и переустановка такого сервера была крайне непростой задачей.
А при появлении нового сервера приходилось крепко думать, будет ли он контроллером домена или нет. Так как изменить его назначение без переустановки было невозможно.
Также схема один PDC – много BDC имела серьезные проблемы с репликацией, особенно для удаленных филиалов с учетом скоростей и качества каналов связи того времени. При том, что удаленный филиал сам не мог внести необходимые данные в домен, так как для этого требовался первичный контроллер.
Поэтому с приходом Windows 2000 и Active Directory от данной схемы отказались, с этого момента все контроллеры домена стали равнозначны и каждый из них мог вносить изменения в базу домена, потом обмениваясь измененными данными. А для контроля целостности и уникальности данных были созданы хозяева операций.
Также теперь любой сервер мог стать контроллером домена или перестать им быть без переустановки, что значительно облегчило администрирование и планирование инфраструктуры.
Но несмотря на то, что Active Directory скоро разменяет четверть века многие коллеги все еще продолжают оперировать устаревшими терминами и понятиями системы, которую никогда в глаза не видели.
👍42
Почему иногда лучше не выпендриваться
Третьего дня попросил меня заехать знакомый, сын которого забрал у меня старый процессор R7 2700X. Мол что-то греется сильно.
Ну хорошо, посмотрим. Симптомы классические: в простое температура 50-65 градусов, при любой, даже минимальной нагрузке сразу улетает за 70 С с выходом кулера на 100% оборотов.
Второй симптом – буст практически не работает, процессор пасет задних не переходя планку в 4 ГГц. Открываем, проверяем подошву кулера – теплая, хотя датчик показывает на процессоре 71 градус.
В общем – явно термопаста. Но процессор то поставлен недавно, может вообще пасту забыл? Или пленку с подошвы не снял?
Снимаем кулер, паста есть, полностью засохшая, консистенции жевательной резинки. Кое как стерли с крышки процессора и основания радиатора.
Спрашиваю, мол что за экскременты мамонта намазаны? В ответ сын знакомого обижается, мол никакие это не экскременты, а Arctic MX-5.
Да ну, не поверил я, покажи. Показывает. Похожа на оригинал, коробочку выкинул, но вроде тоже была как надо, со всеми наклейками и сертификатами.
Консистенция вроде нормальная, но какая-то не такая, неоднородная, вместе с пастой выходит маслянистая жидкость. В общем рисковать не стали, взяли в ближайшем DNS DEEPCOOL Z3, паста без особых претензий, крепкий середнячок.
Намазали, собрали. Итог – температура простоя вернулась на 40-45 градусов, появился буст до 4,3 ГГц, а за 70 температура стала выходить уже при работе с высокой нагрузкой.
Проблема решена, но вопрос с пастой все же не давал покоя, подделка? Брак? Стал читать отзывы и выяснил, что Arctic MX-5 снята с производства, так как подвел кто-то из поставщиков (или OEM-производитель) и качество пасты стало сильно неоднородным.
Симптомы точно такие же – расслоение, высыхание. Не у всех, а как повезет. Вполне возможно, что даже в пределах одной партии качество неоднородное, потому что даже за короткий промежуток времени можно найти полярные отзывы, у кого-то все хорошо, у кого-то паста быстро засохла.
Но сей прискорбный факт сильно не афишируется, а паста продолжает продаваться как продукт топового сегмента. Хотя, на самом деле, если вы не энтузиаст и не пытаетесь выжать из железа все что можно и нельзя, то проще не выпендриваться и взять пасту среднего ценового диапазона.
Результат будет плюс-минус тем же, пару градусов в обычных сценариях эксплуатации погоду не делают, а в случае чего и выбросить будет не так жалко.
Третьего дня попросил меня заехать знакомый, сын которого забрал у меня старый процессор R7 2700X. Мол что-то греется сильно.
Ну хорошо, посмотрим. Симптомы классические: в простое температура 50-65 градусов, при любой, даже минимальной нагрузке сразу улетает за 70 С с выходом кулера на 100% оборотов.
Второй симптом – буст практически не работает, процессор пасет задних не переходя планку в 4 ГГц. Открываем, проверяем подошву кулера – теплая, хотя датчик показывает на процессоре 71 градус.
В общем – явно термопаста. Но процессор то поставлен недавно, может вообще пасту забыл? Или пленку с подошвы не снял?
Снимаем кулер, паста есть, полностью засохшая, консистенции жевательной резинки. Кое как стерли с крышки процессора и основания радиатора.
Спрашиваю, мол что за экскременты мамонта намазаны? В ответ сын знакомого обижается, мол никакие это не экскременты, а Arctic MX-5.
Да ну, не поверил я, покажи. Показывает. Похожа на оригинал, коробочку выкинул, но вроде тоже была как надо, со всеми наклейками и сертификатами.
Консистенция вроде нормальная, но какая-то не такая, неоднородная, вместе с пастой выходит маслянистая жидкость. В общем рисковать не стали, взяли в ближайшем DNS DEEPCOOL Z3, паста без особых претензий, крепкий середнячок.
Намазали, собрали. Итог – температура простоя вернулась на 40-45 градусов, появился буст до 4,3 ГГц, а за 70 температура стала выходить уже при работе с высокой нагрузкой.
Проблема решена, но вопрос с пастой все же не давал покоя, подделка? Брак? Стал читать отзывы и выяснил, что Arctic MX-5 снята с производства, так как подвел кто-то из поставщиков (или OEM-производитель) и качество пасты стало сильно неоднородным.
Симптомы точно такие же – расслоение, высыхание. Не у всех, а как повезет. Вполне возможно, что даже в пределах одной партии качество неоднородное, потому что даже за короткий промежуток времени можно найти полярные отзывы, у кого-то все хорошо, у кого-то паста быстро засохла.
Но сей прискорбный факт сильно не афишируется, а паста продолжает продаваться как продукт топового сегмента. Хотя, на самом деле, если вы не энтузиаст и не пытаетесь выжать из железа все что можно и нельзя, то проще не выпендриваться и взять пасту среднего ценового диапазона.
Результат будет плюс-минус тем же, пару градусов в обычных сценариях эксплуатации погоду не делают, а в случае чего и выбросить будет не так жалко.
👍54👀13🤝4
AMD Ryzen Master – полный контроль над вашим процессором Ryzen
Решил я на прошлых выходных поиграться с искусственным интеллектом от компании MSI, а именно запустить MSI AI Engine которая пообещала мне тщательно проанализировать мою работу и согласно полученным результатам наилучшим образом настроить производительность системы.
Ну ОК, только кто же знал, что понимание лучшего у нас с искусственным интеллектом, мягко говоря, расходятся. Но пока ничего не предвещало беды, несколько дней сей интеллект усиленно что-то там анализировал и сказал, что мой профиль – Производительность.
Хорошо, применяем, перезагружаемся и найдите десять отличий, да и не найдете, потому что текущего Ryzen 9 5900X выше крыши для любых задач.
Первые звоночки, что что-то пошло не так прозвучали вечером. Именно прозвучали. Днем фоновый шум и множество запущенных приложений и виртуалок, которые что-то да делали не давали понять, что система охлаждения стала работать по-другому.
А вот вечером, когда я вместо основного компьютера решил поработать с бухгалтерией на ноутбуке сразу стало понятно, что компьютер живет своей жизнью.
У меня система охлаждения представлена достаточно производительной башней и в простое ее не слышно вообще, то, что ПК включен и работает можно обнаружить по миганию индикаторов. При средней нагрузке слышен легкий шелест и только при тяжелой ПК начинает быть отчетливо слышен.
Но чем он занят? А ничем. Короткое исследование показало, что процессор начал агрессивно бустить частоту даже при минимальной нагрузке. До этого 4,8 ГГц я видел только на тяжелых задачах, вроде сборки проекта, рендеринга и т.п.
Теперь подобная частота легко достигалась при запуске видео в браузере. Плюс в простое процессор перестал сбрасывать частоту ниже номинальной 3,7 ГГц. Оно вроде бы и ничего, температуры оставались в пределах нормы, не выбираясь за пределы 70-72 градусов, но постоянный шум вентилятора по малейшему чиху действовал на нервы.
В общем, дооптимизировался ты дядя, работало ведь все нормально, чего ты лез?
Отключении ИИ результата не дало, ну да он свое дело сделал, записал нужное в BIOS, а вы теперь тут живите.
Сбрасывать BIOS тоже не хотелось, так как там много ручных настроек под себя и было просто лень все их возвращать обратно.
Ну должен же быть какой-то иной выход? Должен, беглый поиск показал родную утилиту AMD Ryzen Master, которая способна помочь вам выполнить как максимальный разгон процессора, так и оптимизировать его энергопотребление.
Скачиваем, запускаем и не удивляемся, увидев установленный режим Precision Boost Overdrive, который снимает лимиты на тепловой пакет и процессор начинает буститься без ограничений с оглядкой только на температуру, при достаточно эффективной системе охлаждения буститься он будет сильно, а значит и шуметь, что и произошло.
Вернув данную настройку в Auto OC, удалось без лишнего шума и пыли полностью решить проблему и вернуть работу системы в комфортные для меня рамки.
Вторая интересная опция - Curve Optimizer, которая позволяет оптимизировать кривую, по которой процессор выполняет разгон с учетом особенностей именно вашей системы. Если Intel в подобных расчетах берет только мощность и частоту, то AMD учитывает еще и фактор температуры.
Данная настройка требует обязательной предварительной калибровки, которая длится более часа, включает несколько перезагрузок и представляет собой определенный стресс-тест, в ходе которого утилита будет повышать частоту до достижения лимита по температуре (для данного процессора это 90 градусов, которые были достигнуты при частоте 5 050 МГц).
Т.е. таким образом вы можете тонко настроить автоматический разгон именно с учетом вашей системы охлаждения. Я не стал его калибровать, текущий режим меня вполне устраивает.
В расширенном режиме доступно еще больше настроек, но тут уже надо вникать в тему, зато можно настроить все именно так, как того хочется.
В общем всем владельцам Ryzen есть смысл поработать с данной утилитой даже в базовом режиме.
✅ Официальная ссылка
Решил я на прошлых выходных поиграться с искусственным интеллектом от компании MSI, а именно запустить MSI AI Engine которая пообещала мне тщательно проанализировать мою работу и согласно полученным результатам наилучшим образом настроить производительность системы.
Ну ОК, только кто же знал, что понимание лучшего у нас с искусственным интеллектом, мягко говоря, расходятся. Но пока ничего не предвещало беды, несколько дней сей интеллект усиленно что-то там анализировал и сказал, что мой профиль – Производительность.
Хорошо, применяем, перезагружаемся и найдите десять отличий, да и не найдете, потому что текущего Ryzen 9 5900X выше крыши для любых задач.
Первые звоночки, что что-то пошло не так прозвучали вечером. Именно прозвучали. Днем фоновый шум и множество запущенных приложений и виртуалок, которые что-то да делали не давали понять, что система охлаждения стала работать по-другому.
А вот вечером, когда я вместо основного компьютера решил поработать с бухгалтерией на ноутбуке сразу стало понятно, что компьютер живет своей жизнью.
У меня система охлаждения представлена достаточно производительной башней и в простое ее не слышно вообще, то, что ПК включен и работает можно обнаружить по миганию индикаторов. При средней нагрузке слышен легкий шелест и только при тяжелой ПК начинает быть отчетливо слышен.
Но чем он занят? А ничем. Короткое исследование показало, что процессор начал агрессивно бустить частоту даже при минимальной нагрузке. До этого 4,8 ГГц я видел только на тяжелых задачах, вроде сборки проекта, рендеринга и т.п.
Теперь подобная частота легко достигалась при запуске видео в браузере. Плюс в простое процессор перестал сбрасывать частоту ниже номинальной 3,7 ГГц. Оно вроде бы и ничего, температуры оставались в пределах нормы, не выбираясь за пределы 70-72 градусов, но постоянный шум вентилятора по малейшему чиху действовал на нервы.
В общем, дооптимизировался ты дядя, работало ведь все нормально, чего ты лез?
Отключении ИИ результата не дало, ну да он свое дело сделал, записал нужное в BIOS, а вы теперь тут живите.
Сбрасывать BIOS тоже не хотелось, так как там много ручных настроек под себя и было просто лень все их возвращать обратно.
Ну должен же быть какой-то иной выход? Должен, беглый поиск показал родную утилиту AMD Ryzen Master, которая способна помочь вам выполнить как максимальный разгон процессора, так и оптимизировать его энергопотребление.
Скачиваем, запускаем и не удивляемся, увидев установленный режим Precision Boost Overdrive, который снимает лимиты на тепловой пакет и процессор начинает буститься без ограничений с оглядкой только на температуру, при достаточно эффективной системе охлаждения буститься он будет сильно, а значит и шуметь, что и произошло.
Вернув данную настройку в Auto OC, удалось без лишнего шума и пыли полностью решить проблему и вернуть работу системы в комфортные для меня рамки.
Вторая интересная опция - Curve Optimizer, которая позволяет оптимизировать кривую, по которой процессор выполняет разгон с учетом особенностей именно вашей системы. Если Intel в подобных расчетах берет только мощность и частоту, то AMD учитывает еще и фактор температуры.
Данная настройка требует обязательной предварительной калибровки, которая длится более часа, включает несколько перезагрузок и представляет собой определенный стресс-тест, в ходе которого утилита будет повышать частоту до достижения лимита по температуре (для данного процессора это 90 градусов, которые были достигнуты при частоте 5 050 МГц).
Т.е. таким образом вы можете тонко настроить автоматический разгон именно с учетом вашей системы охлаждения. Я не стал его калибровать, текущий режим меня вполне устраивает.
В расширенном режиме доступно еще больше настроек, но тут уже надо вникать в тему, зато можно настроить все именно так, как того хочется.
В общем всем владельцам Ryzen есть смысл поработать с данной утилитой даже в базовом режиме.
✅ Официальная ссылка
👍53
Service mesh: тренд, необходимость или хайп?
Приглашаем обсудить это на бесплатном вебинаре от учебного центра Слёрм.
Что будет на вебинаре:
➡️ посмотрим на service mesh с разных точек зрения: эксплуатации и разработки;
➡️ обсудим, какие преимущества дает service mesh и какие у него особенности;
➡️ определим основные понятия и посмотрим на примеры реализации service mesh.
И еще, кстати, разберём, бесплатен ли service mesh и какова его реальная цена.
Эксперты встречи — спикеры курсов Слёрма:
— Павел Лакосников, TeamLead SLA в Авито
— Георг Гаал, CTO, Aenix
Когда: 19 февраля в 19:00
👉 Занять место на вебинаре — через бота.
Реклама. ООО "СЛЁРМ". ИНН 3652901451.
Приглашаем обсудить это на бесплатном вебинаре от учебного центра Слёрм.
Что будет на вебинаре:
➡️ посмотрим на service mesh с разных точек зрения: эксплуатации и разработки;
➡️ обсудим, какие преимущества дает service mesh и какие у него особенности;
➡️ определим основные понятия и посмотрим на примеры реализации service mesh.
И еще, кстати, разберём, бесплатен ли service mesh и какова его реальная цена.
Эксперты встречи — спикеры курсов Слёрма:
— Павел Лакосников, TeamLead SLA в Авито
— Георг Гаал, CTO, Aenix
Когда: 19 февраля в 19:00
👉 Занять место на вебинаре — через бота.
Реклама. ООО "СЛЁРМ". ИНН 3652901451.
Прогнозирования выхода твердотельных накопителей из строя
Данный материал основан сугубо на собственных эмпирических наблюдениях и не является официальной информацией. Сугубо собственные наблюдения и логические выводы основанные на анализе статистики отказов.
Как известно любое оборудование имеет свойство отказывать, диски SSD не исключение и основная задача – вовремя понять, что устройство пора менять, не дожидаясь его отхода в страну вечной охоты.
Традиционные показатели, такие как SMART или счетчики износа здесь помогают мало, поэтому мы проанализировали наши случаи отказов и сделали некоторые выводы, которые не претендуют на истину, но могут оказаться полезны. Выводы применимы как к SSD, так и NVMe дискам.
Есть два параметра, сочетание которых указывает на то, что диск работает не нормально и может в ближайшее время выйти из строя.
1️⃣ Первый – это процент использования активного времени диска, в Zabbix это метрика Disk Utilization, в Windows – активное время. Если данная метрика на достаточное время залипает на уровне 100% без заметной дисковой активности или сопровождается активным чтением с небольшой скоростью – то это первый сигнал неблагополучия.
Да, мы можем нагрузить диск на 100%, но при этом будем видеть реальную адекватную нагрузку на чтение или на запись, либо и то и другое вместе.
Если же диск загружен на 100% в отсутствие видимой активности – то это сигнал о том, что он занят какими-то своими делами и на внешние раздражители не реагирует. В целом такого можно добиться на недорогих дисках удалив сразу большой объем данных и когда диск займется уборкой мусора эффект может быть схожим.
Но, повторимся, продолжительное нахождение диска в 100% нагрузке без видимых на то причин – первый и очень характерный симптом выхода из строя.
2️⃣ Второй симптом – это продолжительное интенсивное чтение, не несущее никакого логического смысла или вовсе противоречащее характеру производимой операции.
Скажем вы открываете закладку в браузере и процесс начинает что-то активно и продолжительно читать с диска, подвисая на некоторое время или полностью. Но объем и характер прочитанных данных никак не соответствует выполняемой задаче.
Либо мы пытаемся записать документ в 1С:Предприятие, но процесс вместо того, чтобы выполнить запись начинает интенсивно читать.
Попытка выяснить, что именно читает процесс успеха не приносит. Он может читать что угодно: свой бинарник, свою базу, своп, кеш.
А может и вообще ничего не читать. Т.е. у нас нет активно читающего процесса, а диск показывает, что его активно кто-то читает. Система или процесс, вызвавший такое поведение или подвисают, или существенно тормозят.
Попутно все это сопровождается 100% загрузкой диска. В Zabbix это можно отследить по увеличению метрике Disk read time (rate), в Windows мы просто видим продолжительное чтение.
👆 Еще раз повторим, что каждая из указанных метрик может вырастать по различным причинам, но их устойчивое сочетание в совокупности с «непонятным» чтением «непонятных» данных – это характерный признак скорого выхода из строя.
Данный материал основан сугубо на собственных эмпирических наблюдениях и не является официальной информацией. Сугубо собственные наблюдения и логические выводы основанные на анализе статистики отказов.
Как известно любое оборудование имеет свойство отказывать, диски SSD не исключение и основная задача – вовремя понять, что устройство пора менять, не дожидаясь его отхода в страну вечной охоты.
Традиционные показатели, такие как SMART или счетчики износа здесь помогают мало, поэтому мы проанализировали наши случаи отказов и сделали некоторые выводы, которые не претендуют на истину, но могут оказаться полезны. Выводы применимы как к SSD, так и NVMe дискам.
Есть два параметра, сочетание которых указывает на то, что диск работает не нормально и может в ближайшее время выйти из строя.
1️⃣ Первый – это процент использования активного времени диска, в Zabbix это метрика Disk Utilization, в Windows – активное время. Если данная метрика на достаточное время залипает на уровне 100% без заметной дисковой активности или сопровождается активным чтением с небольшой скоростью – то это первый сигнал неблагополучия.
Да, мы можем нагрузить диск на 100%, но при этом будем видеть реальную адекватную нагрузку на чтение или на запись, либо и то и другое вместе.
Если же диск загружен на 100% в отсутствие видимой активности – то это сигнал о том, что он занят какими-то своими делами и на внешние раздражители не реагирует. В целом такого можно добиться на недорогих дисках удалив сразу большой объем данных и когда диск займется уборкой мусора эффект может быть схожим.
Но, повторимся, продолжительное нахождение диска в 100% нагрузке без видимых на то причин – первый и очень характерный симптом выхода из строя.
2️⃣ Второй симптом – это продолжительное интенсивное чтение, не несущее никакого логического смысла или вовсе противоречащее характеру производимой операции.
Скажем вы открываете закладку в браузере и процесс начинает что-то активно и продолжительно читать с диска, подвисая на некоторое время или полностью. Но объем и характер прочитанных данных никак не соответствует выполняемой задаче.
Либо мы пытаемся записать документ в 1С:Предприятие, но процесс вместо того, чтобы выполнить запись начинает интенсивно читать.
Попытка выяснить, что именно читает процесс успеха не приносит. Он может читать что угодно: свой бинарник, свою базу, своп, кеш.
А может и вообще ничего не читать. Т.е. у нас нет активно читающего процесса, а диск показывает, что его активно кто-то читает. Система или процесс, вызвавший такое поведение или подвисают, или существенно тормозят.
Попутно все это сопровождается 100% загрузкой диска. В Zabbix это можно отследить по увеличению метрике Disk read time (rate), в Windows мы просто видим продолжительное чтение.
👆 Еще раз повторим, что каждая из указанных метрик может вырастать по различным причинам, но их устойчивое сочетание в совокупности с «непонятным» чтением «непонятных» данных – это характерный признак скорого выхода из строя.
👍53🤔7👀1
This media is not supported in your browser
VIEW IN TELEGRAM
Забавный видосик в Клубе ДНС на странице с ошибками 500. Еще более забавно присмотреться какую именно команду вводит гусь.
🔥42😁33👍9
Авгиевы конюшни
Случилась тут на днях беда – неожиданно и скоропостижно скончался, немного подергавшись твердотельный накопитель в рабочем ПК.
Вместе с накопителем в страну вечной охоты отправилось свыше 700 ГБ данных. Я специально не написал ценных – ничего ценного там не было.
Данный накопитель изначально использовался в целях разработки и тестирования. На нем находились дорабатываемые базы 1С, исходники проектов и скриптов, базы для тестирования и т.д. и т.п.
Конечный результат работ в виде бинарников и релизов хранился на другом диске с обязательной синхронизацией в облако, а вся разработка синхронизировалась с git и внешними репозиториями.
Т.е. ценного не пропало ничего, ну кроме тестовых баз. Но их наплодить не проблема, ну и актуальные проекты заново разместить надо было, что неспеша с перерывами на кофе было сделано за полдня.
Но заметка не о том, а о хранимом там объеме данных, свыше 700 ГБ чего? А непонятно чего. У меня давно чесались руки навести там порядок, но сделать это никогда не удавалось.
Почему? Потому что каждый раз возникали отговорки, мол может пригодится, мол сильно есть не просит. Мол не помню, что это, надо или не надо ( с учетом что последнее изменение было несколько лет назад – точно не надо). И т.д. и т.п.
Год от года все это росло и пухло, занимало все больше места, под это дело покупался более емкий диск и так бы оно и шло, но случай кардинально изменил ситуацию.
Восстановив все рабочие проекты, мы с удивлением обнаружили, что рабочий объем информации составляет всего 106 ГБ, ну со всякими промежуточными сборками, тестовыми релизами и т.п. раздуется до 200 ГБ, может быть.
Фактически ½ терабайта хлама заботливо хранилось годами. Не нужное, так как, напомню, и результаты работы и код хранятся в другом месте. И по-хорошему сделать это надо было давно, просто все грохнуть и заново создать рабочие проекты.
Но у кого же рука поднимется… Вот так и живем.
Случилась тут на днях беда – неожиданно и скоропостижно скончался, немного подергавшись твердотельный накопитель в рабочем ПК.
Вместе с накопителем в страну вечной охоты отправилось свыше 700 ГБ данных. Я специально не написал ценных – ничего ценного там не было.
Данный накопитель изначально использовался в целях разработки и тестирования. На нем находились дорабатываемые базы 1С, исходники проектов и скриптов, базы для тестирования и т.д. и т.п.
Конечный результат работ в виде бинарников и релизов хранился на другом диске с обязательной синхронизацией в облако, а вся разработка синхронизировалась с git и внешними репозиториями.
Т.е. ценного не пропало ничего, ну кроме тестовых баз. Но их наплодить не проблема, ну и актуальные проекты заново разместить надо было, что неспеша с перерывами на кофе было сделано за полдня.
Но заметка не о том, а о хранимом там объеме данных, свыше 700 ГБ чего? А непонятно чего. У меня давно чесались руки навести там порядок, но сделать это никогда не удавалось.
Почему? Потому что каждый раз возникали отговорки, мол может пригодится, мол сильно есть не просит. Мол не помню, что это, надо или не надо ( с учетом что последнее изменение было несколько лет назад – точно не надо). И т.д. и т.п.
Год от года все это росло и пухло, занимало все больше места, под это дело покупался более емкий диск и так бы оно и шло, но случай кардинально изменил ситуацию.
Восстановив все рабочие проекты, мы с удивлением обнаружили, что рабочий объем информации составляет всего 106 ГБ, ну со всякими промежуточными сборками, тестовыми релизами и т.п. раздуется до 200 ГБ, может быть.
Фактически ½ терабайта хлама заботливо хранилось годами. Не нужное, так как, напомню, и результаты работы и код хранятся в другом месте. И по-хорошему сделать это надо было давно, просто все грохнуть и заново создать рабочие проекты.
Но у кого же рука поднимется… Вот так и живем.
👍43💯15😁6
А есть ли у вас подобные "Авгиевы конюшни"
Anonymous Poll
55%
Есть, как не быть
15%
Иногда нахожу силы немного разгрести
16%
Время от времени разгребаю
4%
Постоянно поддерживаю порядок
4%
Забей, купи еще один диск
0%
Никогда такого не допускаю
6%
Я Авгий, мне результат посмотреть
👍2
❓ Хотите работать в VK, но не знаете, с чего начать?
Слёрм запускает крутой проект: серия онлайн-встреч с лидами из бигтеха!
Мы встречаемся с руководителями VK, чтобы выяснить, как проходят отборы на позицию DevOps Middle и помочь вам успешно пройти собеседование.
📅 Встречаемся с коллегами из VK Cloud – 17 февраля в 17:00!
На встрече разберём:
✔️ Какие задачи решает DevOps Middle в команде VK Cloud
✔️ Топ-3 ключевые компетенции DevOps-инженера
✔️ Разбор технических знаний: от critical до nice to have
✔️ Red flags при найме
✔️ Чему готовы обучать в процессе работы
Ведущий — Вячеслав Федосеев, TeamLead DevOps в «Честном знаке», автор канала «DevOps Bootcamp с Федосеевым»
В гостях:
Иван Дудко — руководитель команды автоматизации разработки VK Cloud, VK Tech
Мария Турунова — HR-бизнес-партнёр, VK Tech
Приходите 17 февраля в 17:00, чтобы понять, как попасть в VK и прокачать свои навыки!
📌 Ссылка на трансляцию – в боте!
#реклама
О рекламодателе
erid: 2W5zFG6WDma
Слёрм запускает крутой проект: серия онлайн-встреч с лидами из бигтеха!
Мы встречаемся с руководителями VK, чтобы выяснить, как проходят отборы на позицию DevOps Middle и помочь вам успешно пройти собеседование.
📅 Встречаемся с коллегами из VK Cloud – 17 февраля в 17:00!
На встрече разберём:
✔️ Какие задачи решает DevOps Middle в команде VK Cloud
✔️ Топ-3 ключевые компетенции DevOps-инженера
✔️ Разбор технических знаний: от critical до nice to have
✔️ Red flags при найме
✔️ Чему готовы обучать в процессе работы
Ведущий — Вячеслав Федосеев, TeamLead DevOps в «Честном знаке», автор канала «DevOps Bootcamp с Федосеевым»
В гостях:
Иван Дудко — руководитель команды автоматизации разработки VK Cloud, VK Tech
Мария Турунова — HR-бизнес-партнёр, VK Tech
Приходите 17 февраля в 17:00, чтобы понять, как попасть в VK и прокачать свои навыки!
📌 Ссылка на трансляцию – в боте!
#реклама
О рекламодателе
erid: 2W5zFG6WDma
🤡6👎1