Windows Me – не то время, не то место…
Еще одна «провальная» ОС от Microsoft - Windows Me (Millenium Edition), которую у нас стали скоро называть «линолеум едишен», а на Западе «Mistake Edition» (версия-ошибка).
Хотя, если честно, так сильно хаять Millenium было не за что, просто она появилась не в то время и не в том месте, а потому оказалась некоторым недоразумением, от новой ОС тогда ожидали совсем иного.
Если мы вернемся немного назад, к моменту выпуска Windows 98, то уже тода Билл Гейтс заявил, что это будет последняя система в линейке Win 9x и все следующие ОС будут основаны на линейке NT.
Как раз тогда в разработке находился новый проект NT 5, который станет позже Windows 2000 и в этой линейке первоначально планировалась версия Windows 2000 Home, которая базировалась на проекте Neptune.
Но разработка Neptune задерживалась, а позже и вообще была свернута и объединена с еще одним проектом Odyssey в Whistler, который позже вышел как Windows XP, а пока в Microsoft исходили из того, что им нечего предложить домашним пользователям после выпуска Windows 2000.
Поэтому возникла идея выпустить Neptune «на минималках», взяв за основу привычную Win 9x и перенести туда что получится из проекта Neptune. А так как последний был NT-системой из линейки Windows 2000 (NT 5), то и внешний вид новой системы стал похож на своего старшего брата.
Это можно заметить буквально во всем, в загрузочном экране, иконках, наборе цветов и т.д. и т.п. Для пользователей 9х это было достаточно свежо и современно.
Также новая система предложила расширенную поддержку мультимедиа и современного оборудования, зарождающейся сети интернет и многое из того, что сегодня воспринимается как должное.
Но тогда это было что-то действительно новое, скажем Windows Media Player 7.0 или Windows Movie Maker, именно начиная с этой версии всторенные мультимедийные приложения начали выглядеть современно и начали поддерживать современные функции.
Еще одно важное новшество – это Восстановление системы, штатный инструмент, который позволял делать снимки состояния системы и откатываться на них. Да, работал он через пень-колоду, но раньше ни в линейке 9x, ни в NT ничего подобного не было.
Но откуда же столько негативных отзывов и эти снисходительные прозвища? А дело в том, что MS решила приблизить новую ОС к линейке NT и убрала из нее реальный режим DOS.
Но напомним, что вся линейка 9х являлась гибридной 16/32 битной ОС на ядре DOS, несмотря на все внешнее великолепие основа этого шикарного особняка покоилась на фундаменте старой халупы.
Все это привело к тому, что в новой ОС стало невозможно просто так запустить приложения, требовавшие реального режима DOS (чаще всего игры), также отвалился огромный пласт старого оборудования, который использовал DOS-драйвера.
Также ряд старых приложений мог работать в новой системе нестабильно, вызывая многочисленные сбои и перезагрузки. Что и повлекло за собой имидж системы как «глючной».
Но на самом деле Windows Me была вполне стабильна, в том смысле в котором этот термин применим ко всей линейке 9х.
Пользователи с современным железом и периферией не испытывали проблем, а производительность графики в 9x всегда была выше, чем в NT и это делало Me неплохим выбором в качестве игровой системы.
Но по этому же самому поводу она являлась выбором и владельцев устаревших систем, которые начали испытывать с ней серьезные проблемы.
И оно бы, может быть, все утряслось и уладилось, но через год в сентябре 2001 на рынок вышла Windows XP и завоевала там феерический успех.
После чего Windows Me стала никому не нужна, все самое новое и прогрессивное было в новой ОС, а старые системы остались на проверенной временем Windows 98SE такой расклад существовал примерно до середины нулевых.
Хотя в других обстоятельствах Windows Me могла бы избавиться от детских болезней и стать достойной ОС в линейке 9x, но увы, она появилась в совершенно неподходящее время и была выпущена сугубо как страховка от неудачи Windows XP.
Еще одна «провальная» ОС от Microsoft - Windows Me (Millenium Edition), которую у нас стали скоро называть «линолеум едишен», а на Западе «Mistake Edition» (версия-ошибка).
Хотя, если честно, так сильно хаять Millenium было не за что, просто она появилась не в то время и не в том месте, а потому оказалась некоторым недоразумением, от новой ОС тогда ожидали совсем иного.
Если мы вернемся немного назад, к моменту выпуска Windows 98, то уже тода Билл Гейтс заявил, что это будет последняя система в линейке Win 9x и все следующие ОС будут основаны на линейке NT.
Как раз тогда в разработке находился новый проект NT 5, который станет позже Windows 2000 и в этой линейке первоначально планировалась версия Windows 2000 Home, которая базировалась на проекте Neptune.
Но разработка Neptune задерживалась, а позже и вообще была свернута и объединена с еще одним проектом Odyssey в Whistler, который позже вышел как Windows XP, а пока в Microsoft исходили из того, что им нечего предложить домашним пользователям после выпуска Windows 2000.
Поэтому возникла идея выпустить Neptune «на минималках», взяв за основу привычную Win 9x и перенести туда что получится из проекта Neptune. А так как последний был NT-системой из линейки Windows 2000 (NT 5), то и внешний вид новой системы стал похож на своего старшего брата.
Это можно заметить буквально во всем, в загрузочном экране, иконках, наборе цветов и т.д. и т.п. Для пользователей 9х это было достаточно свежо и современно.
Также новая система предложила расширенную поддержку мультимедиа и современного оборудования, зарождающейся сети интернет и многое из того, что сегодня воспринимается как должное.
Но тогда это было что-то действительно новое, скажем Windows Media Player 7.0 или Windows Movie Maker, именно начиная с этой версии всторенные мультимедийные приложения начали выглядеть современно и начали поддерживать современные функции.
Еще одно важное новшество – это Восстановление системы, штатный инструмент, который позволял делать снимки состояния системы и откатываться на них. Да, работал он через пень-колоду, но раньше ни в линейке 9x, ни в NT ничего подобного не было.
Но откуда же столько негативных отзывов и эти снисходительные прозвища? А дело в том, что MS решила приблизить новую ОС к линейке NT и убрала из нее реальный режим DOS.
Но напомним, что вся линейка 9х являлась гибридной 16/32 битной ОС на ядре DOS, несмотря на все внешнее великолепие основа этого шикарного особняка покоилась на фундаменте старой халупы.
Все это привело к тому, что в новой ОС стало невозможно просто так запустить приложения, требовавшие реального режима DOS (чаще всего игры), также отвалился огромный пласт старого оборудования, который использовал DOS-драйвера.
Также ряд старых приложений мог работать в новой системе нестабильно, вызывая многочисленные сбои и перезагрузки. Что и повлекло за собой имидж системы как «глючной».
Но на самом деле Windows Me была вполне стабильна, в том смысле в котором этот термин применим ко всей линейке 9х.
Пользователи с современным железом и периферией не испытывали проблем, а производительность графики в 9x всегда была выше, чем в NT и это делало Me неплохим выбором в качестве игровой системы.
Но по этому же самому поводу она являлась выбором и владельцев устаревших систем, которые начали испытывать с ней серьезные проблемы.
И оно бы, может быть, все утряслось и уладилось, но через год в сентябре 2001 на рынок вышла Windows XP и завоевала там феерический успех.
После чего Windows Me стала никому не нужна, все самое новое и прогрессивное было в новой ОС, а старые системы остались на проверенной временем Windows 98SE такой расклад существовал примерно до середины нулевых.
Хотя в других обстоятельствах Windows Me могла бы избавиться от детских болезней и стать достойной ОС в линейке 9x, но увы, она появилась в совершенно неподходящее время и была выпущена сугубо как страховка от неудачи Windows XP.
1👍19❤4👨💻3🤮2💯2
Насколько критично использовать ECC-память для ZFS. Часть_2
В прошлой части мы рассмотрели общее влияние ошибок памяти на ZFS и выяснили, что риск возникновения таких ошибок невелик, а риск повреждения пользовательских данных еще ниже.
А как быть с самой ZFS, может ли такая ошибка привести к полному разрушению или критическому повреждению файловой системы?
Давайте снова обратимся к статистическому материалу от Google, который содержит данные о вероятности повреждения при возникновении ошибок памяти метаданных ZFS, что теоретически может привести (но не обязательно приведет) к повреждению структуры ZFS.
▫️ 1 DIMM – 0,0428%
▫️ 4 DIMM – 0,171%
▫️ 8 DIMM – 0,341%
С одной стороны, это немного, например, для типичной системы с четырьмя модулями DIMM вероятность повреждения метаданных составит 0,17% в год или 1 случай из 585.
Много это или мало? Для этого давайте сравним вероятность ошибки в памяти с другими событиями, потенциально могущими привести к потере пула, за основу возьмем систему с 4 DIMM и промежуток в 5 лет:
▫️Ошибка в метаданных из-за не-ECC (4 DIMM) – 0,85%
▫️Отказ одного диска в RAID-Z1 – 5-14%
▫️Одновременный отказ 2 дисков в RAID-Z1 – 2,5%
▫️Ошибка администратора (rm -rf, zfs destroy) 2,5-9,6%
Как видим, вероятность разрушения ZFS по причине ошибки в памяти в несколько раз ниже вероятности выхода из строя сразу двух дисков в массиве и еще ниже возможной человеческой ошибки.
Но говорит ли это, что ECC -память для ZFS не нужна? Нет, раз в год и палка стреляет и если есть возможность использовать ECC, то ее нужно использовать. Если же нет, то стоит понимать, что у вас появляются дополнительные риски, которые следует учитывать.
Также следует понимать, что все сказанное выше относится к любой файловой системе, а не только ZFS.
Что касается ZFS, то воспринимать ее как панацею, обеспечивающую надежное хранение тоже не следует. Да, ZFS защищает ваши данные лучше, чем иные файловые системы, но она также имеет точки отказа и может подвергнуться сбоям.
В прошлой части мы рассмотрели общее влияние ошибок памяти на ZFS и выяснили, что риск возникновения таких ошибок невелик, а риск повреждения пользовательских данных еще ниже.
А как быть с самой ZFS, может ли такая ошибка привести к полному разрушению или критическому повреждению файловой системы?
Давайте снова обратимся к статистическому материалу от Google, который содержит данные о вероятности повреждения при возникновении ошибок памяти метаданных ZFS, что теоретически может привести (но не обязательно приведет) к повреждению структуры ZFS.
▫️ 1 DIMM – 0,0428%
▫️ 4 DIMM – 0,171%
▫️ 8 DIMM – 0,341%
С одной стороны, это немного, например, для типичной системы с четырьмя модулями DIMM вероятность повреждения метаданных составит 0,17% в год или 1 случай из 585.
Много это или мало? Для этого давайте сравним вероятность ошибки в памяти с другими событиями, потенциально могущими привести к потере пула, за основу возьмем систему с 4 DIMM и промежуток в 5 лет:
▫️Ошибка в метаданных из-за не-ECC (4 DIMM) – 0,85%
▫️Отказ одного диска в RAID-Z1 – 5-14%
▫️Одновременный отказ 2 дисков в RAID-Z1 – 2,5%
▫️Ошибка администратора (rm -rf, zfs destroy) 2,5-9,6%
Как видим, вероятность разрушения ZFS по причине ошибки в памяти в несколько раз ниже вероятности выхода из строя сразу двух дисков в массиве и еще ниже возможной человеческой ошибки.
Но говорит ли это, что ECC -память для ZFS не нужна? Нет, раз в год и палка стреляет и если есть возможность использовать ECC, то ее нужно использовать. Если же нет, то стоит понимать, что у вас появляются дополнительные риски, которые следует учитывать.
Также следует понимать, что все сказанное выше относится к любой файловой системе, а не только ZFS.
Что касается ZFS, то воспринимать ее как панацею, обеспечивающую надежное хранение тоже не следует. Да, ZFS защищает ваши данные лучше, чем иные файловые системы, но она также имеет точки отказа и может подвергнуться сбоям.
👍20🤔2❤1
Предсказуемые имена сетевых интерфейсов systemd
Начиная с версии 197, systemd/udev автоматически назначает предсказуемые, стабильные имена сетевых интерфейсов для всех сетевых интерфейсов. Это решение было встречено, скажем мягко, неоднозначно. Поэтому в данной заметке мы расскажем для чего это сделано и какие проблемы решает.
Начнем с классической схемы с eth, первоначально она базировалась на опросе ядром сетевых устройств по мере их появления, а так как порядок загрузки драйверов может носить случайный характер, то eth0 при следующей загрузке мог стать eth1 и наоборот.
Долгое время для решения этой проблемы использовалась схема присвоения имен на основе MAC-адресов, но она имела существенные недостатки в виде необходимости root-доступа на запись файловой системы и способность впадать в состояние гонки при подключении нового устройства.
С появлением виртуализации возникли новые сложности, связанные с тем, что MAC-адреса сетевых интерфейсов виртуальных машин не являются фиксированными и могут меняться.
Другой применяемый подход – biosdevname, в этом случае ядро пыталось считать из BIOS топологию сетевого устройства по принципу порт – индекс – слот и на этом основании присваивать сетевые имена.
Недостаток данного подхода - он полностью неприменим для не x86 устройств.
Но в целом biosdevname предлагал здравый поход: имена полностью автоматические, полностью предсказуемые, они остаются фиксированными, даже если оборудование добавляется или удаляется (т. е. не происходит повторного нумерации), и сломанное оборудование можно без проблем заменить.
В systemd реализована схема во многом похожая на biosdevname, но более развитая и предполагающее большее сходство имен сетевых интерфейсов с именами других устройств, например, блочных.
Она состоит из нескольких политик:
1️⃣ Имена, включающие индексные номера прошивки/BIOS для встроенных устройств (например: eno1)
2️⃣ Имена, включающие индексные номера слотов PCI Express, предоставленные прошивкой/BIOS (например: ens1)
3️⃣ Имена, включающие физическое/географическое расположение разъема оборудования (например: enp2s0)
4️⃣ Имена, включающие MAC-адрес интерфейсов (например: enx78e7d1ea46da)
5️⃣ Классическое, непредсказуемое именование ethX, встроенное в ядро (например: eth0)
Выбор имени происходит следующим образом: политика 3 если она применима и доступна, иначе переход к политике 2, от нее к политике 1. Если не одна политика не подходит, то применяется политика 5.
Политика 4 никогда автоматически не применяется, но может быть включена системным администратором.
Политика 5 применяется только в крайнем случае. Это означает, что, если в системе установлено имя biosdevname, оно будет иметь приоритет. Если пользователь добавил правила udev, которые изменяют имена устройств ядра, они также будут иметь приоритет. Кроме того, любые схемы именования, специфичные для дистрибутива, также будут иметь приоритет.
Таким образом система предоставляет постоянные и предсказуемые имена для сетевого оборудования вне зависимости от версии драйверов и ядра, а также марки оборудования.
Такие имена не меняются при добавлении или удалении оборудования и сохраняются при его замене. Также это гарантирует неизменность имен в виртуальных средах. И, кроме того, не требуется root-доступ на запись файловой системы.
К недостаткам данной схемы можно отнести некоторую начальную неопределенность, ранее в системе с одним сетевым адаптером он гарантированно был eth0, теперь его наименование следует уточнить перед настройкой.
Начиная с версии 197, systemd/udev автоматически назначает предсказуемые, стабильные имена сетевых интерфейсов для всех сетевых интерфейсов. Это решение было встречено, скажем мягко, неоднозначно. Поэтому в данной заметке мы расскажем для чего это сделано и какие проблемы решает.
Начнем с классической схемы с eth, первоначально она базировалась на опросе ядром сетевых устройств по мере их появления, а так как порядок загрузки драйверов может носить случайный характер, то eth0 при следующей загрузке мог стать eth1 и наоборот.
Долгое время для решения этой проблемы использовалась схема присвоения имен на основе MAC-адресов, но она имела существенные недостатки в виде необходимости root-доступа на запись файловой системы и способность впадать в состояние гонки при подключении нового устройства.
С появлением виртуализации возникли новые сложности, связанные с тем, что MAC-адреса сетевых интерфейсов виртуальных машин не являются фиксированными и могут меняться.
Другой применяемый подход – biosdevname, в этом случае ядро пыталось считать из BIOS топологию сетевого устройства по принципу порт – индекс – слот и на этом основании присваивать сетевые имена.
Недостаток данного подхода - он полностью неприменим для не x86 устройств.
Но в целом biosdevname предлагал здравый поход: имена полностью автоматические, полностью предсказуемые, они остаются фиксированными, даже если оборудование добавляется или удаляется (т. е. не происходит повторного нумерации), и сломанное оборудование можно без проблем заменить.
В systemd реализована схема во многом похожая на biosdevname, но более развитая и предполагающее большее сходство имен сетевых интерфейсов с именами других устройств, например, блочных.
Она состоит из нескольких политик:
1️⃣ Имена, включающие индексные номера прошивки/BIOS для встроенных устройств (например: eno1)
2️⃣ Имена, включающие индексные номера слотов PCI Express, предоставленные прошивкой/BIOS (например: ens1)
3️⃣ Имена, включающие физическое/географическое расположение разъема оборудования (например: enp2s0)
4️⃣ Имена, включающие MAC-адрес интерфейсов (например: enx78e7d1ea46da)
5️⃣ Классическое, непредсказуемое именование ethX, встроенное в ядро (например: eth0)
Выбор имени происходит следующим образом: политика 3 если она применима и доступна, иначе переход к политике 2, от нее к политике 1. Если не одна политика не подходит, то применяется политика 5.
Политика 4 никогда автоматически не применяется, но может быть включена системным администратором.
Политика 5 применяется только в крайнем случае. Это означает, что, если в системе установлено имя biosdevname, оно будет иметь приоритет. Если пользователь добавил правила udev, которые изменяют имена устройств ядра, они также будут иметь приоритет. Кроме того, любые схемы именования, специфичные для дистрибутива, также будут иметь приоритет.
Таким образом система предоставляет постоянные и предсказуемые имена для сетевого оборудования вне зависимости от версии драйверов и ядра, а также марки оборудования.
Такие имена не меняются при добавлении или удалении оборудования и сохраняются при его замене. Также это гарантирует неизменность имен в виртуальных средах. И, кроме того, не требуется root-доступ на запись файловой системы.
К недостаткам данной схемы можно отнести некоторую начальную неопределенность, ранее в системе с одним сетевым адаптером он гарантированно был eth0, теперь его наименование следует уточнить перед настройкой.
👍30😢3❤2🤮2👌2
Настройка языка и региональных стандартов в Ubuntu или Debian
Данный вопрос достаточно простой, но очень часто про него забывают, вспоминая только тогда, когда это выходит боком. Поэтому лучше сразу уделить внимание этому вопросу и выполнить такую настройку первым делом после установки системы.
Начнем с правильной установки локали, так как именно от нее могут зависеть настройки по умолчанию устанавливаемого ПО и в некоторых случаях их уже не удастся поменять просто и безболезненно.
Для этого выполните команду:
Перед вами появится большой список локалей – выбираем из них необходимые, обычно достаточно выбрать ru_RU.UTF-8, в некоторых случаях может понадобиться еще en_US.UTF-8, следующим шагом укажите выбранную консоль для использования по умолчанию.
После чего система сгенерирует указанные вами локали и установит выбранную локалью по умолчанию.
Теперь настроим консоль, это необходимо для нормального отображения символов в оболочке:
В Debian пакета console-setup может не оказаться, в таком случае выполните:
И повторите предыдущую команду.
На самом первом экране безальтернативно выбираем UTF-8, затем находим и выбираем набор символов Latin; Slavic Cyrillic; Greek. Остальные настройки можете выбрать на свой вкус (размер символов, шрифт и т.д.)
И в заключение сразу правильно установим часовой пояс:
Ничего сложного там нет, выбираем нужный континент и часовой пояс, применяем настройки.
После всех выполненных действий операционную систему следует перезагрузить.
Данный вопрос достаточно простой, но очень часто про него забывают, вспоминая только тогда, когда это выходит боком. Поэтому лучше сразу уделить внимание этому вопросу и выполнить такую настройку первым делом после установки системы.
Начнем с правильной установки локали, так как именно от нее могут зависеть настройки по умолчанию устанавливаемого ПО и в некоторых случаях их уже не удастся поменять просто и безболезненно.
Для этого выполните команду:
dpkg-reconfigure locales
Перед вами появится большой список локалей – выбираем из них необходимые, обычно достаточно выбрать ru_RU.UTF-8, в некоторых случаях может понадобиться еще en_US.UTF-8, следующим шагом укажите выбранную консоль для использования по умолчанию.
После чего система сгенерирует указанные вами локали и установит выбранную локалью по умолчанию.
Теперь настроим консоль, это необходимо для нормального отображения символов в оболочке:
dpkg-reconfigure console-setup
В Debian пакета console-setup может не оказаться, в таком случае выполните:
apt install console-setup
И повторите предыдущую команду.
На самом первом экране безальтернативно выбираем UTF-8, затем находим и выбираем набор символов Latin; Slavic Cyrillic; Greek. Остальные настройки можете выбрать на свой вкус (размер символов, шрифт и т.д.)
И в заключение сразу правильно установим часовой пояс:
dpkg-reconfigure tzdata
Ничего сложного там нет, выбираем нужный континент и часовой пояс, применяем настройки.
После всех выполненных действий операционную систему следует перезагрузить.
👍37👌5🔥2❤1
Порядок запуска гостевых систем в Proxmox VE
Proxmox, как и любая взрослая система виртуализации предоставляет богатые инструменты для управления работой гостевых систем (виртуальных машин и контейнеров), одним из важных параметров работы узла является порядок запуска гостевых систем.
Пока гостей мало обычно этот вопрос не встает на повестке дня, но как только их количество увеличивается и появляются достаточно тяжелые системы, то вопрос начинает вставать ребром.
Начнем с того, что ваша дисковая подсистема может не выдержать одновременного запуска такого количества гостевых систем и серьезно просядет по производительности, в результате чего вы будете бегать вокруг и ждать, когда же оно наконец загрузится.
Также не будет ничего хорошего, если сервер приложений запустится раньше обсуживающего его сервера БД или сетевого хранилища. В общем таких ситуаций может быть много и ничего хорошего из них не получится.
Поэтому берем управление порядком загрузки в свои руки, а именно разделяем гостевые системы по степени важности и критичности, учитывая зависимости между ними.
Первыми ставим наиболее важные системы, обеспечивающие функционирование все инфраструктуры: роутеры, VPN-сервера, DNS, DHCP и т.д. и т.п.
Далее можем запустить контроллеры домена, за ними СУБД, потом сервера приложений, потом все остальное.
Настроить все это можно прямо в графическом интерфейсе в разделе Options виртуальной машины, прежде всего активируйте опцию Start at boot, которая включает автоматическую загрузку гостевой системы.
Затем откройте настройку Start/Shutdown order, где вы можете указать порядок загрузки/выключения, для этого можете использовать любые целые положительные числа.
При включении узла гипервизор проверяет все гостевые системы, у которых включена автозагрузка и строит очередь согласно указанным значением порядка. Очередь у контейнеров и виртуальных машин общая.
Первыми запускаются гостевые системы с самым низким порядком, последними те, у которых порядок не указан совсем. Гости с одинаковым номером порядка запускаются одновременно.
Но запущенная гостевая система вовсе не означает ее готовность к работе, загрузка нужных служб может занимать время и если это критично для зависящих от них гостевых систем, то мы можем поставить дополнительную задержку, которую указываем в параметре Startup delay в секундах.
Эта опция часто вызывает неверное понимание, многие считают, что она определяет задержку старта гостевой системы, однако это не так, данная задержка влияет только на запуск гостей следующей очереди.
Если задержек установлено несколько, то отработает самая длительная из них. И только после этого начнут загружаться гостевые системы следующей очереди. Без указания порядка очереди эта настройка бессмысленна.
Выключение происходит в обратном порядке, сначала гости без указания порядка, потом от самого большого номера очереди к самому маленькому. Задержки при выключении не используются, как только выключились все гостевые системы одной очереди тут же, выключается другая.
Параметр Shutdown timeout устанавливает тайм-аут на выключение, по умолчанию 60 секунд, если гостевая система не завершила свою работу за указанное время, то в лог пишется ошибка выключения и гостевая система завершается принудительно.
Если у вас есть тяжелые машины, которые долго выключаются, то имеет смысл увеличить данный параметр, чтобы гостевой системе хватало времени корректно завершить процессы, а если это какая-то тестовая лаборатория и вы хотите, чтобы она быстрее выключалась, то таймаут можно уменьшить.
Proxmox, как и любая взрослая система виртуализации предоставляет богатые инструменты для управления работой гостевых систем (виртуальных машин и контейнеров), одним из важных параметров работы узла является порядок запуска гостевых систем.
Пока гостей мало обычно этот вопрос не встает на повестке дня, но как только их количество увеличивается и появляются достаточно тяжелые системы, то вопрос начинает вставать ребром.
Начнем с того, что ваша дисковая подсистема может не выдержать одновременного запуска такого количества гостевых систем и серьезно просядет по производительности, в результате чего вы будете бегать вокруг и ждать, когда же оно наконец загрузится.
Также не будет ничего хорошего, если сервер приложений запустится раньше обсуживающего его сервера БД или сетевого хранилища. В общем таких ситуаций может быть много и ничего хорошего из них не получится.
Поэтому берем управление порядком загрузки в свои руки, а именно разделяем гостевые системы по степени важности и критичности, учитывая зависимости между ними.
Первыми ставим наиболее важные системы, обеспечивающие функционирование все инфраструктуры: роутеры, VPN-сервера, DNS, DHCP и т.д. и т.п.
Далее можем запустить контроллеры домена, за ними СУБД, потом сервера приложений, потом все остальное.
Настроить все это можно прямо в графическом интерфейсе в разделе Options виртуальной машины, прежде всего активируйте опцию Start at boot, которая включает автоматическую загрузку гостевой системы.
Затем откройте настройку Start/Shutdown order, где вы можете указать порядок загрузки/выключения, для этого можете использовать любые целые положительные числа.
При включении узла гипервизор проверяет все гостевые системы, у которых включена автозагрузка и строит очередь согласно указанным значением порядка. Очередь у контейнеров и виртуальных машин общая.
Первыми запускаются гостевые системы с самым низким порядком, последними те, у которых порядок не указан совсем. Гости с одинаковым номером порядка запускаются одновременно.
Но запущенная гостевая система вовсе не означает ее готовность к работе, загрузка нужных служб может занимать время и если это критично для зависящих от них гостевых систем, то мы можем поставить дополнительную задержку, которую указываем в параметре Startup delay в секундах.
Эта опция часто вызывает неверное понимание, многие считают, что она определяет задержку старта гостевой системы, однако это не так, данная задержка влияет только на запуск гостей следующей очереди.
Если задержек установлено несколько, то отработает самая длительная из них. И только после этого начнут загружаться гостевые системы следующей очереди. Без указания порядка очереди эта настройка бессмысленна.
Выключение происходит в обратном порядке, сначала гости без указания порядка, потом от самого большого номера очереди к самому маленькому. Задержки при выключении не используются, как только выключились все гостевые системы одной очереди тут же, выключается другая.
Параметр Shutdown timeout устанавливает тайм-аут на выключение, по умолчанию 60 секунд, если гостевая система не завершила свою работу за указанное время, то в лог пишется ошибка выключения и гостевая система завершается принудительно.
Если у вас есть тяжелые машины, которые долго выключаются, то имеет смысл увеличить данный параметр, чтобы гостевой системе хватало времени корректно завершить процессы, а если это какая-то тестовая лаборатория и вы хотите, чтобы она быстрее выключалась, то таймаут можно уменьшить.
11👍43❤6🥱2
Войти в айти
Был недавно в гостях у знакомых и сразу, чуть ли не с порога первый вопрос – как сейчас лучше войти в айти. Ну да понятно, у них сын этой весной школу будет заканчивать и вопрос выбора будущей профессии стоит остро.
Посидел, попил чая, с будущим коллегой побеседовал и не увидел у него вообще ни желания, ни интереса, ни каких бы там ни было способностей к этому делу.
Спрашиваю, а зачем в айти то, не самая простая отрасль, как никак, да еще и постоянного самообразования требует.
На что услышал, мол ладно тебе, все равно у айтишников самые высокие зарплаты и работают в тепле и уюте, сидя за компьютером, а еще можно удаленно из дома работать.
В целом они в чем-то правы и даже у начинающего айтишника зарплата если не будет самой высокой по рынку, то все равно будет выше, чем у начинающих в других отраслях.
И если с нашей, отраслевой точки зрения, зарплаты отдельных юных падаванов невелики, то с точки зрения широких народных масс – они достаточно высоки, особенно за то, что эти самые айтишники сидят в тепле и ничего не делают.
Поэтому можно говорить, что в обществе давно сложилось понимание айти как некой синекуры, куда надо только попасть, а потом катайся как сыр в масле. На самом деле все конечно сложнее, но мнение уже сложилось.
Масла в огонь подбавляют и всевозможные курсы, и даже государственные программы по переквалификации самых широких народных масс населения в айтишников.
Государство понять можно, с нынешними темпами цифровизации и импортозамещения ему срочно нужны специалисты нижнего звена, в достаточном для их массового использования количестве.
Плюс айти всячески популяризуется у молодого поколения, о чем мы только что писали выше.
Нынешние высокие заработные платы в IT обусловлены двумя вещами: дефицитом специалистов и достаточно высокой добавочной стоимостью, таким специалистом производимой.
Но и трудятся такие специалисты преимущественно в коммерческой сфере, где никто терпеть лентяев и дураков не будет: или ты работаешь и получаешь нормальные деньги или идешь на улицу.
Войти в такое айти просто так сложно, какие бы дипломы и корочки у тебя не были. В коммерции на диплом смотрят в последнюю очередь. Ты или умеешь и делаешь, либо не умеешь и проходишь мимо и неважно кто-то по специальности: программист или ветеринар.
А вот в госсекторе все по-иному, там можно годами ничего не делать, просто имитируя рабочий процесс и красиво отчитываясь наверх, плюс присутствуют достаточно специфичные взаимоотношения, которые лучше всего характеризуются поговоркой: «я начальник – ты дурак, ты начальник – я дурак».
Нормальные специалисты в госсектор не спешат. Частично из-за невысоких по отраслевым меркам зарплат, а частично из-за специфики рабочих отношений (скажем так). А кто и прибивается – так ненадолго, ну или в случае, если больше никуда не берут.
Поэтому именно государству сегодня выгодно выбросить на рынок большое количество начинающих айтишников. Которые, прекрасно понимая сами, что айтишники они «ненастоящие» не будут страдать излишними амбициями и пойдут туда, где тепло, светло и деньги платят, т.е. преимущественно в госсектор.
Хотя кто-то, возможно, и откроет в себе новые способности, но это будут именно штучные случаи. Аналогичный эффект даст и массовый приток молодежи на айти специальности. Появится обширный рынок молодых специалистов, хотя и невысокой квалификации.
А что это значит? А это значит, что уровень зарплаты в этом сегменте резко пойдет вниз, по-другому никак, если по рынку труда бегают стада молодых (и не очень) айтишников, желающих просто найти работу по специальности.
Повлияет ли это на уровень зарплат в отрасли в целом? Нет. Опытные специалисты как были, так и останутся востребованы. А вот существующий сейчас перекос, когда даже молодой и зеленый айтишник получает выше среднего – выправит.
А вообще история повторяется. В начале нулевых модно было быть юристом. И где сейчас все эти стада молодых юристов? А хороших что тогда, что сейчас приходится поискать и получают они более чем достойно.
Был недавно в гостях у знакомых и сразу, чуть ли не с порога первый вопрос – как сейчас лучше войти в айти. Ну да понятно, у них сын этой весной школу будет заканчивать и вопрос выбора будущей профессии стоит остро.
Посидел, попил чая, с будущим коллегой побеседовал и не увидел у него вообще ни желания, ни интереса, ни каких бы там ни было способностей к этому делу.
Спрашиваю, а зачем в айти то, не самая простая отрасль, как никак, да еще и постоянного самообразования требует.
На что услышал, мол ладно тебе, все равно у айтишников самые высокие зарплаты и работают в тепле и уюте, сидя за компьютером, а еще можно удаленно из дома работать.
В целом они в чем-то правы и даже у начинающего айтишника зарплата если не будет самой высокой по рынку, то все равно будет выше, чем у начинающих в других отраслях.
И если с нашей, отраслевой точки зрения, зарплаты отдельных юных падаванов невелики, то с точки зрения широких народных масс – они достаточно высоки, особенно за то, что эти самые айтишники сидят в тепле и ничего не делают.
Поэтому можно говорить, что в обществе давно сложилось понимание айти как некой синекуры, куда надо только попасть, а потом катайся как сыр в масле. На самом деле все конечно сложнее, но мнение уже сложилось.
Масла в огонь подбавляют и всевозможные курсы, и даже государственные программы по переквалификации самых широких народных масс населения в айтишников.
Государство понять можно, с нынешними темпами цифровизации и импортозамещения ему срочно нужны специалисты нижнего звена, в достаточном для их массового использования количестве.
Плюс айти всячески популяризуется у молодого поколения, о чем мы только что писали выше.
Нынешние высокие заработные платы в IT обусловлены двумя вещами: дефицитом специалистов и достаточно высокой добавочной стоимостью, таким специалистом производимой.
Но и трудятся такие специалисты преимущественно в коммерческой сфере, где никто терпеть лентяев и дураков не будет: или ты работаешь и получаешь нормальные деньги или идешь на улицу.
Войти в такое айти просто так сложно, какие бы дипломы и корочки у тебя не были. В коммерции на диплом смотрят в последнюю очередь. Ты или умеешь и делаешь, либо не умеешь и проходишь мимо и неважно кто-то по специальности: программист или ветеринар.
А вот в госсекторе все по-иному, там можно годами ничего не делать, просто имитируя рабочий процесс и красиво отчитываясь наверх, плюс присутствуют достаточно специфичные взаимоотношения, которые лучше всего характеризуются поговоркой: «я начальник – ты дурак, ты начальник – я дурак».
Нормальные специалисты в госсектор не спешат. Частично из-за невысоких по отраслевым меркам зарплат, а частично из-за специфики рабочих отношений (скажем так). А кто и прибивается – так ненадолго, ну или в случае, если больше никуда не берут.
Поэтому именно государству сегодня выгодно выбросить на рынок большое количество начинающих айтишников. Которые, прекрасно понимая сами, что айтишники они «ненастоящие» не будут страдать излишними амбициями и пойдут туда, где тепло, светло и деньги платят, т.е. преимущественно в госсектор.
Хотя кто-то, возможно, и откроет в себе новые способности, но это будут именно штучные случаи. Аналогичный эффект даст и массовый приток молодежи на айти специальности. Появится обширный рынок молодых специалистов, хотя и невысокой квалификации.
А что это значит? А это значит, что уровень зарплаты в этом сегменте резко пойдет вниз, по-другому никак, если по рынку труда бегают стада молодых (и не очень) айтишников, желающих просто найти работу по специальности.
Повлияет ли это на уровень зарплат в отрасли в целом? Нет. Опытные специалисты как были, так и останутся востребованы. А вот существующий сейчас перекос, когда даже молодой и зеленый айтишник получает выше среднего – выправит.
А вообще история повторяется. В начале нулевых модно было быть юристом. И где сейчас все эти стада молодых юристов? А хороших что тогда, что сейчас приходится поискать и получают они более чем достойно.
👍33😁5❤3👌3🤡2
Заменит ли ИИ системных администраторов
Вот уже не один раз за последнее время читатели задают один и тот же вопрос, а заменит ли ИИ системных администраторов? А если и не заменит, то не сократит ли значительно рынок труда.
Вопрос интересный и я тоже думал об этом, сегодня почти весь день провел в разъездах, встречах, разговорах и уже ближе к вечеру разговорился за кофе со знакомой главной бухгалтером одной подшефной конторы.
А разговор как-то неожиданно зашел про ИИ, я ее прямо спросил – пользуешься? Она ответила утвердительно и сказала, что, в общем и целом, довольна полученным результатом.
Что делает? Да точно также спихнула на него всю рутину: проверки, сверки, поиск расхождений и все такое прочее. Иногда заставляет искать что-то новое в сети, разбирать непонятные и редкие ситуации.
Спрашиваю – не фантазирует? Фантазирует – говорит, мол как без этого, но я же не дура, я же вижу, что его куда-то не туда понесло, сразу могу направить правильным путем. И вообще, чем более четко ставишь задачу, тем лучше результат.
И если раньше, чтобы «прокрыжить» месяц надо было либо убить пару часов, либо загрузить на полдня девочку, то сетка сделает это минут за пять. Причем ничего не упустит и точно все найдет, в отличие от девочки.
Получается, говорю, что ИИ все-таки заменяет бухгалтеров, на что она на момент задумалась, а потом сказала – нет. Потому что, если быть честными, то все эти девочки – они не бухгалтера на самом деле, хотя формально ими числятся.
Все что они могут – это вносить первичку, разносить платежи и делать еще множество монотонных и нудных повседневных задач, не требующих ни квалификации, ни глубокого понимания. Самостоятельно вести учет даже какого-нибудь простого ИП они не смогут.
Ничего не напоминает? В нашей отрасли дела обстоят примерно также, кто такой настоящий системны администратор? Это человек обладающий инженерным мышлением, умеющий проводить причинно-следственные связи и строить гипотезы при недостатке информации.
А также принимать решения в условиях цейтнота и психологического давления. Когда все упало и надо все срочно поднимать или когда что-то пошло не так и надо вернуть все, как было до окончания технологического окна.
Одновременно с этим кому-то надо читать логи, смотреть мониторинг, заполнять отчеты, сидеть на первой линии поддержки и все такое прочее. Можно ли этих сотрудников назвать администраторами? Давайте скажем честно – нет. В лучшем случае помощниками администратора.
И вот их ИИ спокойно заменит, потому что он не ленится, не сачкует, а просто быстро, спокойно и качественно делает всю рутину. У него не болит голова после вчерашнего, с ним не ругается жена и он не решает личные вопросы в рабочее время.
И что самое смешное, товарищей, меняющих картриджи и вытаскивающих замятую бумагу ИИ не заменит, просто потому что не умеет. А вот сотрудников первой линии поддержки, помощников и младших сотрудников – запросто.
Но тут давайте снова будем честны, это не администраторы, это младший технический персонал, самостоятельно инфраструктуру, даже простую, они не потянут. А бизнес он не про благотворительность, он про прибыль и лишние дармоеды ему не нужны.
Поэтому мораль сей басни будет очень проста. Либо вы представляете собой самостоятельную профессиональную единицу, либо ИИ скоро займет ваше место. Если вы действительно профессионал – то ИИ станет вашим помощником и заменит нескольких раздолбаев.
Иначе – вам придется конкурировать с ним на рынке труда и шансы будут далеко не в вашу пользу.
Поэтому, если вы решили серьезно работать в сфере IT, то вам придется действительно стать хорошим специалистом, который может и умеет, либо уступить рабочее место ИИ и пойти туда, что ИИ еще не осилил – работу руками.
Вот уже не один раз за последнее время читатели задают один и тот же вопрос, а заменит ли ИИ системных администраторов? А если и не заменит, то не сократит ли значительно рынок труда.
Вопрос интересный и я тоже думал об этом, сегодня почти весь день провел в разъездах, встречах, разговорах и уже ближе к вечеру разговорился за кофе со знакомой главной бухгалтером одной подшефной конторы.
А разговор как-то неожиданно зашел про ИИ, я ее прямо спросил – пользуешься? Она ответила утвердительно и сказала, что, в общем и целом, довольна полученным результатом.
Что делает? Да точно также спихнула на него всю рутину: проверки, сверки, поиск расхождений и все такое прочее. Иногда заставляет искать что-то новое в сети, разбирать непонятные и редкие ситуации.
Спрашиваю – не фантазирует? Фантазирует – говорит, мол как без этого, но я же не дура, я же вижу, что его куда-то не туда понесло, сразу могу направить правильным путем. И вообще, чем более четко ставишь задачу, тем лучше результат.
И если раньше, чтобы «прокрыжить» месяц надо было либо убить пару часов, либо загрузить на полдня девочку, то сетка сделает это минут за пять. Причем ничего не упустит и точно все найдет, в отличие от девочки.
Получается, говорю, что ИИ все-таки заменяет бухгалтеров, на что она на момент задумалась, а потом сказала – нет. Потому что, если быть честными, то все эти девочки – они не бухгалтера на самом деле, хотя формально ими числятся.
Все что они могут – это вносить первичку, разносить платежи и делать еще множество монотонных и нудных повседневных задач, не требующих ни квалификации, ни глубокого понимания. Самостоятельно вести учет даже какого-нибудь простого ИП они не смогут.
Ничего не напоминает? В нашей отрасли дела обстоят примерно также, кто такой настоящий системны администратор? Это человек обладающий инженерным мышлением, умеющий проводить причинно-следственные связи и строить гипотезы при недостатке информации.
А также принимать решения в условиях цейтнота и психологического давления. Когда все упало и надо все срочно поднимать или когда что-то пошло не так и надо вернуть все, как было до окончания технологического окна.
Одновременно с этим кому-то надо читать логи, смотреть мониторинг, заполнять отчеты, сидеть на первой линии поддержки и все такое прочее. Можно ли этих сотрудников назвать администраторами? Давайте скажем честно – нет. В лучшем случае помощниками администратора.
И вот их ИИ спокойно заменит, потому что он не ленится, не сачкует, а просто быстро, спокойно и качественно делает всю рутину. У него не болит голова после вчерашнего, с ним не ругается жена и он не решает личные вопросы в рабочее время.
И что самое смешное, товарищей, меняющих картриджи и вытаскивающих замятую бумагу ИИ не заменит, просто потому что не умеет. А вот сотрудников первой линии поддержки, помощников и младших сотрудников – запросто.
Но тут давайте снова будем честны, это не администраторы, это младший технический персонал, самостоятельно инфраструктуру, даже простую, они не потянут. А бизнес он не про благотворительность, он про прибыль и лишние дармоеды ему не нужны.
Поэтому мораль сей басни будет очень проста. Либо вы представляете собой самостоятельную профессиональную единицу, либо ИИ скоро займет ваше место. Если вы действительно профессионал – то ИИ станет вашим помощником и заменит нескольких раздолбаев.
Иначе – вам придется конкурировать с ним на рынке труда и шансы будут далеко не в вашу пользу.
Поэтому, если вы решили серьезно работать в сфере IT, то вам придется действительно стать хорошим специалистом, который может и умеет, либо уступить рабочее место ИИ и пойти туда, что ИИ еще не осилил – работу руками.
👍40👎9❤6💯3
Анализируем загрузку вашей Linux системы при помощи systemd-analyze
Многие администраторы задаются вопросом – что задерживает загрузку их Linux системы, какие службы и как влияют на этот процесс. Желательно в цифрах и фактах.
Возможно, вы удивитесь, но все это в вашей системе уже есть, с цифрами, фактами и графиками. Достаточно воспользоваться утилитой systemd-analyze.
Если вы просто запустите ее, то получите общее время загрузки системы разделенные на этапы загрузки ядра и пользовательского окружения. Понятно, что такой информации мало, поэтому будем детализировать.
Прежде всего получим список процессов, влияющих на загрузку и отсортированных по времени запуска:
Также можно построить зависимостей и времени запуска критических сервисов:
Для анализа вам может пригодиться график загрузки, для его построения используйте:
А этой командой можно построить граф зависимостей сервисов в формате DOT, но сам по себе он мало интересен, потому как полный граф системы представляет собой сильно запутанное и нечитаемое дерево, куда интереснее получить граф для отдельно взятой службы или таргета.
Для преобразования DOT-файла в график вам потребуется установить пакет
После чего выполните команду:
И в папке запуска скоро появится интересующий вас график, по которому можно изучить все зависимости юнита. Обратите внимание, что имя сервиса нужно писать полностью, с указанием типа юнита.
Многие администраторы задаются вопросом – что задерживает загрузку их Linux системы, какие службы и как влияют на этот процесс. Желательно в цифрах и фактах.
Возможно, вы удивитесь, но все это в вашей системе уже есть, с цифрами, фактами и графиками. Достаточно воспользоваться утилитой systemd-analyze.
Если вы просто запустите ее, то получите общее время загрузки системы разделенные на этапы загрузки ядра и пользовательского окружения. Понятно, что такой информации мало, поэтому будем детализировать.
Прежде всего получим список процессов, влияющих на загрузку и отсортированных по времени запуска:
systemd-analyze blame
Также можно построить зависимостей и времени запуска критических сервисов:
systemd-analyze critical-chain
Для анализа вам может пригодиться график загрузки, для его построения используйте:
systemd-analyze plot > boot.svg
А этой командой можно построить граф зависимостей сервисов в формате DOT, но сам по себе он мало интересен, потому как полный граф системы представляет собой сильно запутанное и нечитаемое дерево, куда интереснее получить граф для отдельно взятой службы или таргета.
Для преобразования DOT-файла в график вам потребуется установить пакет
graphviz:apt install graphviz
После чего выполните команду:
systemd-analyze dot docker.service | dot -Tsvg > docker.svg
И в папке запуска скоро появится интересующий вас график, по которому можно изучить все зависимости юнита. Обратите внимание, что имя сервиса нужно писать полностью, с указанием типа юнита.
1👍33❤2🔥2🤡2
MultiDrive – бесплатная утилита для работы с дисками
Утилиты для работы с дисками в Windows – отдельная категория программ, которые работают с критически важным оборудованием – дисками и пользовательскими данными.
У многих администраторов уже выработался свой набор программ, но чаще всего это коммерческие решения, что не всегда подходит, особенно если речь идет о лицензионной чистоте или заказчик не хочет приобретать дополнительный софт.
Не так давно мы открыли для себя утилиту MultiDrive от компании Atola Technology. На первый взгляд она ничем не выделяется среди аналогов. Простой и понятный интерфейс, необходимый минимум функций.
Программа умеет клонировать, создавать резервные копии дисков и восстанавливать их, а также делать очистку с гарантированным уничтожением данных. Все достаточно просто и наглядно, запутаться решительно негде.
Это делает ее пригодной как для опытных специалистов, так и для обычных пользователей, которым просто надо клонировать старый диск на новый. Или сделать резервную копию системы.
Данное ПО не является открытым, но распространяется бесплатно для личного и коммерческого применения. Компания разработчик может собирать статистику использования, но эту функцию нужно явно включить и спокойно отключить в настройках.
Кроме самой утилиты вы можете скачать загрузочный диск с ней на базе WinPE, что делает ее полноценным и универсальным инструментом.
Но самое интересное – наличие собственного CLI, которое позволяет использовать утилиту в сценариях автоматизации. CLI полностью свой, но достаточно прост и отлично документирован.
При необходимости вы можете вызвать дополнительную справку по любой команде с подробным перечислением всех ключей, примерами использования и расшифровкой применяемых сокращений.
В общем, перед нами добротно сделанный бесплатный продукт, который можно и нужно использовать в повседневной деятельности.
Утилиты для работы с дисками в Windows – отдельная категория программ, которые работают с критически важным оборудованием – дисками и пользовательскими данными.
У многих администраторов уже выработался свой набор программ, но чаще всего это коммерческие решения, что не всегда подходит, особенно если речь идет о лицензионной чистоте или заказчик не хочет приобретать дополнительный софт.
Не так давно мы открыли для себя утилиту MultiDrive от компании Atola Technology. На первый взгляд она ничем не выделяется среди аналогов. Простой и понятный интерфейс, необходимый минимум функций.
Программа умеет клонировать, создавать резервные копии дисков и восстанавливать их, а также делать очистку с гарантированным уничтожением данных. Все достаточно просто и наглядно, запутаться решительно негде.
Это делает ее пригодной как для опытных специалистов, так и для обычных пользователей, которым просто надо клонировать старый диск на новый. Или сделать резервную копию системы.
Данное ПО не является открытым, но распространяется бесплатно для личного и коммерческого применения. Компания разработчик может собирать статистику использования, но эту функцию нужно явно включить и спокойно отключить в настройках.
Кроме самой утилиты вы можете скачать загрузочный диск с ней на базе WinPE, что делает ее полноценным и универсальным инструментом.
Но самое интересное – наличие собственного CLI, которое позволяет использовать утилиту в сценариях автоматизации. CLI полностью свой, но достаточно прост и отлично документирован.
При необходимости вы можете вызвать дополнительную справку по любой команде с подробным перечислением всех ключей, примерами использования и расшифровкой применяемых сокращений.
В общем, перед нами добротно сделанный бесплатный продукт, который можно и нужно использовать в повседневной деятельности.
11👍31🔥9❤2
Выгрузка и загрузка информационных баз 1С при помощи автономного сервера
При работе с информационными базами 1С:Предприятие очень часто возникают задачи выгрузить или загрузить дамп информационной базы или ее конфигурацию.
Обычно для этих целей используют Конфигуратор, но данный способ имеет ряд неудобств. Во-первых, Конфигуратор требует монопольного доступа к базе, т.е. выгнать из нее всех пользователей.
Во-вторых, могут быть сложности с серверами на Linux без графического окружения, а так как Конфигуратор работает в режиме толстого клиента, то все данные в полном объеме гоняются по сети, таким образом удаленная работа на медленном канале становится попросту невозможной.
От всех этих недостатков вас может избавить Автономный сервер, который поставляется вместе с платформой и располагается в папке
В нашем примере будет использована платформа Linux, но все команды будут прекрасно работать и в среде Windows.
Будем считать, что мы находимся в директории с бинарными файлами платформы, а дампы и конфигурации будем располагать в домашнем каталоге текущего пользователя.
Начнем с самого популярного, выгрузки базы в DT-файл:
В целом параметры в комментариях не нуждаются, только уточним что в опции --db-server мы указываем имя или адрес сервера базы данных и указываем учетные данные также от сервера СУБД.
Параметр --dbms указывает тип СУБД, можете использовать
Выгонять пользователей для этого не нужно, но помните, что в возможно нарушение целостности создаваемого файла выгрузки.
Кроме того, следует помнить, что выгрузка информационной базы не является средством резервного копирования!
Загрузить базу можно обратной командой:
Для выгрузки конфигурации используйте:
Для загрузки:
После загрузки конфигурации вам потребуется обновить конфигурацию базы данных:
В данной заметке мы коснулись лишь малой части того, что умеет автономный сервер, показав лишь самые часто используемые операции. Больше информации можно найти в официальной документации.
При работе с информационными базами 1С:Предприятие очень часто возникают задачи выгрузить или загрузить дамп информационной базы или ее конфигурацию.
Обычно для этих целей используют Конфигуратор, но данный способ имеет ряд неудобств. Во-первых, Конфигуратор требует монопольного доступа к базе, т.е. выгнать из нее всех пользователей.
Во-вторых, могут быть сложности с серверами на Linux без графического окружения, а так как Конфигуратор работает в режиме толстого клиента, то все данные в полном объеме гоняются по сети, таким образом удаленная работа на медленном канале становится попросту невозможной.
От всех этих недостатков вас может избавить Автономный сервер, который поставляется вместе с платформой и располагается в папке
bin под именем ibcmd.В нашем примере будет использована платформа Linux, но все команды будут прекрасно работать и в среде Windows.
Будем считать, что мы находимся в директории с бинарными файлами платформы, а дампы и конфигурации будем располагать в домашнем каталоге текущего пользователя.
Начнем с самого популярного, выгрузки базы в DT-файл:
./ibcmd infobase dump --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.dt
В целом параметры в комментариях не нуждаются, только уточним что в опции --db-server мы указываем имя или адрес сервера базы данных и указываем учетные данные также от сервера СУБД.
Параметр --dbms указывает тип СУБД, можете использовать
PostgreSQL или MSSQLServer. Выгонять пользователей для этого не нужно, но помните, что в возможно нарушение целостности создаваемого файла выгрузки.
Кроме того, следует помнить, что выгрузка информационной базы не является средством резервного копирования!
Загрузить базу можно обратной командой:
./ibcmd infobase restore --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.dt
Для выгрузки конфигурации используйте:
./ibcmd infobase config save --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.cf
Для загрузки:
./ibcmd infobase config load --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.cf
После загрузки конфигурации вам потребуется обновить конфигурацию базы данных:
./ibcmd infobase config apply --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1
В данной заметке мы коснулись лишь малой части того, что умеет автономный сервер, показав лишь самые часто используемые операции. Больше информации можно найти в официальной документации.
👍27🤯4❤3👀1🤝1
Резервное копирование файловых баз 1С:Предприятие в S3 хранилище
Данную заметку мы начнем с описания проблематики, потому как она достаточно специфична и именно ей обусловлены принятые нами при разработке скрипта решения.
Файловые базы – это малый или даже средний бизнес, вполне нормальные и платежеспособные клиенты, но с одной особенностью – 1С:Предприятие нужна только для отчетности и зарплаты, поэтому работают с ней пару-тройку человек, преимущественно удаленно.
Сегодня стандарт де-факто – это публикация файловой базы на веб-сервере, что обеспечивает нормальный уровень производительности и спокойно позволяет организовать удаленный доступ к ней без лишних затрат.
Кроме этого, всегда будет хотя бы одно место, как правило, локальное, к которому база подключена напрямую, это связано с необходимостью устанавливать патчи, обновления, расширения и т.д.
На все это накладывается неопределенный режим работы и отсутствие четкого технологического окна. Градации там могут быть разные, от включен постоянно, до утром включили, вечером выключили.
Поэтому угадать время, когда в базе никого нет сложно, даже глухой ночью может висеть активный сеанс, хорошо если он ничего не делает, а если там групповое перепроведение или еще какая обработка запущена?
И если веб-сеансы мы можем относительно безопасно для базы отключить, то завершить локальный сеанс безопасно невозможно, только завершением процесса 1С. А это может привести к совершенно разным последствиям.
Поэтому нам нужно выгружать копию безопасно и не выгоняя пользователей, такой способ есть – Автономный сервер 1С:Предприятие, он позволяет выгрузить дамп базы – DT, не выгоняя пользователей.
Насколько корректна будет такая выгрузка? С точки зрения физической структуры это будет нормальный, полноценный дамп.
С логической? Целостность дампа сохраняется на момент его создания, если в это время в базе работали или была запущена незавершенная транзакция, то дамп будет неконсистентным.
В обычных СУБД такие вопросы решаются автоматически, в файловой 1С вам поможет проверка логической целостности в конфигураторе. Но в любом случае у вас будет рабочая база, просто без части данных.
Но ровно тоже самое вы получите и при использовании pg_dump или простой модели восстановления MS SQL, так что тут полный паритет. Да и не нужно небольшим базам восстановление на момент времени.
Также стоит помнить, что DT – это сырой дамп, а не резервная копия и сам вендор обращает на это внимание, вы можете спокойно выгрузить DT из поврежденной базе, который потом не сможете загрузить.
Но в нашем сценарии DT – это оптимальный вариант, в том числе и потому, что мы можем назвать файл как нам нравится, а для его загрузки надо запустить нужную базу в конфигураторе.
В то время как сам файл базы зовется исключительно 1Cv8.1CD и ничего не стоит перепутать файлы или заменить не тот файл, а такие случаи на нашем опыте случались не раз и не два.
Теперь почему S3 – сегодня это самый дешевый способ внешнего хранения данных и один из самых безопасных, особенно если хранилище поддерживает версионирование.
В итоге, собрав все эти требования воедино и приведя к единому знаменателю мы совместно с Claude написали и отладили скрипт. Скрипт писали «по-взрослому», все настройки хранятся в отдельных файлах, сам скрипт вам трогать не нужно.
В комплекте у вас будет 4 файла:
▫️Backup-1C-ToS3.ps1 – сам скрипт
▫️Backup-1C-ToS3.bat – файл-стартер для ручного запуска
▫️config.ini – настройки подключения к S3-хранилищу
▫️databases.lst – список файловых баз, пути к ним и учетные данные для входа
Все файлы отлично прокомментированы и содержат краткие инструкции по применению. Единственный момент, так как писалось все это конкретно под S3 Selectel, то в комментах и примерах фигурирует именно он, но скрипт будет работать с любым S3 хранилищем.
Из зависимостей вам потребуется Автономный сервер (устанавливается с компонентой сервера 1С, если сервер не нужен снимите флаг его установки в качестве службы) и AWS CLI.
Данную заметку мы начнем с описания проблематики, потому как она достаточно специфична и именно ей обусловлены принятые нами при разработке скрипта решения.
Файловые базы – это малый или даже средний бизнес, вполне нормальные и платежеспособные клиенты, но с одной особенностью – 1С:Предприятие нужна только для отчетности и зарплаты, поэтому работают с ней пару-тройку человек, преимущественно удаленно.
Сегодня стандарт де-факто – это публикация файловой базы на веб-сервере, что обеспечивает нормальный уровень производительности и спокойно позволяет организовать удаленный доступ к ней без лишних затрат.
Кроме этого, всегда будет хотя бы одно место, как правило, локальное, к которому база подключена напрямую, это связано с необходимостью устанавливать патчи, обновления, расширения и т.д.
На все это накладывается неопределенный режим работы и отсутствие четкого технологического окна. Градации там могут быть разные, от включен постоянно, до утром включили, вечером выключили.
Поэтому угадать время, когда в базе никого нет сложно, даже глухой ночью может висеть активный сеанс, хорошо если он ничего не делает, а если там групповое перепроведение или еще какая обработка запущена?
И если веб-сеансы мы можем относительно безопасно для базы отключить, то завершить локальный сеанс безопасно невозможно, только завершением процесса 1С. А это может привести к совершенно разным последствиям.
Поэтому нам нужно выгружать копию безопасно и не выгоняя пользователей, такой способ есть – Автономный сервер 1С:Предприятие, он позволяет выгрузить дамп базы – DT, не выгоняя пользователей.
Насколько корректна будет такая выгрузка? С точки зрения физической структуры это будет нормальный, полноценный дамп.
С логической? Целостность дампа сохраняется на момент его создания, если в это время в базе работали или была запущена незавершенная транзакция, то дамп будет неконсистентным.
В обычных СУБД такие вопросы решаются автоматически, в файловой 1С вам поможет проверка логической целостности в конфигураторе. Но в любом случае у вас будет рабочая база, просто без части данных.
Но ровно тоже самое вы получите и при использовании pg_dump или простой модели восстановления MS SQL, так что тут полный паритет. Да и не нужно небольшим базам восстановление на момент времени.
Также стоит помнить, что DT – это сырой дамп, а не резервная копия и сам вендор обращает на это внимание, вы можете спокойно выгрузить DT из поврежденной базе, который потом не сможете загрузить.
Но в нашем сценарии DT – это оптимальный вариант, в том числе и потому, что мы можем назвать файл как нам нравится, а для его загрузки надо запустить нужную базу в конфигураторе.
В то время как сам файл базы зовется исключительно 1Cv8.1CD и ничего не стоит перепутать файлы или заменить не тот файл, а такие случаи на нашем опыте случались не раз и не два.
Теперь почему S3 – сегодня это самый дешевый способ внешнего хранения данных и один из самых безопасных, особенно если хранилище поддерживает версионирование.
В итоге, собрав все эти требования воедино и приведя к единому знаменателю мы совместно с Claude написали и отладили скрипт. Скрипт писали «по-взрослому», все настройки хранятся в отдельных файлах, сам скрипт вам трогать не нужно.
В комплекте у вас будет 4 файла:
▫️Backup-1C-ToS3.ps1 – сам скрипт
▫️Backup-1C-ToS3.bat – файл-стартер для ручного запуска
▫️config.ini – настройки подключения к S3-хранилищу
▫️databases.lst – список файловых баз, пути к ним и учетные данные для входа
Все файлы отлично прокомментированы и содержат краткие инструкции по применению. Единственный момент, так как писалось все это конкретно под S3 Selectel, то в комментах и примерах фигурирует именно он, но скрипт будет работать с любым S3 хранилищем.
Из зависимостей вам потребуется Автономный сервер (устанавливается с компонентой сервера 1С, если сервер не нужен снимите флаг его установки в качестве службы) и AWS CLI.
12👍22🔥9❤8🤝1
Сервис лицензирования 1С – плюсы и минусы
В обсуждениях многие упоминали и планировали развертывание сервера лицензирования 1С, поэтому мы решили отдельным материалом осветить все достоинства и недостатки такого решения.
Начнем с того, что правильно такое решение называется именно Сервис лицензирования, а не Сервер лицензирования, но второй вариант давно прижился и его также можно использовать, только следует понимать, что речь идет об одном и том же.
Сервис лицензирования представляет отдельную серверную инсталляцию в кластере серверов, которая содержит только одноименную службу (Назначение функциональности в терминах 1С) и не требует для запуска отдельной серверной лицензии.
Сервис лицензирования может выдавать серверные и клиентские многопользовательские лицензии, последние всегда выдаются только на сеанс, вне зависимости от режима подключения клиента.
Минимальные требования к сервису лицензирования – два ядра и 4 ГБ оперативной памяти, хотя последнее требование на наш взгляд несколько завышено.
Также следует помнить, что сервис лицензирования не работает с HASP-ключами и не может привязать лицензию к такому ключу.
Еще один важный момент – сервис лицензирования не работает с клиентскими подключениями, а выдает лицензии только серверу (серверам), который в свою очередь может выдать ее клиенту.
Версия платформы и разрядность сервиса лицензирования должна совпадать с версией платформы или разрядностью рабочих серверов.
При запуске на одном узле нескольких экземпляров сервера 1С:Предприятие при получении лицензии из сервиса лицензирования вам потребуется отдельная лицензия на каждый запущенный экземпляр.
При этом на сервисе лицензирования также потребуется установить и запустить на разных портах несколько экземпляров сервера 1С.
При работе терминального сервера лицензия будет выдаваться не на терминальный сеанс, допускающий неограниченное число сеансов 1С:Предприятие, а на каждый сеанс 1С.
Как видим, особенностей у сервиса лицензирования хватает и подходить к его развертыванию следует взвешенно, проанализировав все плюсы и минусы относительно собственной ситуации.
Так, например, в однозначные плюсы можно записать возможность изменять параметры компьютера или виртуальной машины сервера 1С без необходимости повторной активации лицензии.
А в столь же однозначные минусы то, что теперь два экземпляра сервера на одном узле потребуют две серверных лицензии вместо одной.
Что касается клиентских лицензий, то здесь ситуация не меняется, за исключением терминального сервера.
Но есть и плюс, при наличии нескольких серверов в кластере они могут использовать для выдачи клиентам общий пул лицензий, что исключает ситуации, когда на сервере А лицензии закончились, а на сервере Б их еще с избытком.
Ну и не забываем о том, что наличие сервиса лицензирования совсем не означает необходимости переноса всех лицензий на него. Вы можете перенести только те лицензии, которые считаете нужным, а другие оставить непосредственно на серверах.
Если сильно упростить ситуацию, то поиск лицензии будет происходить следующим образом: сначала на клиенте, потом на сервере, потом на сервисе лицензирования.
В заключение хочется сказать, что сервис лицензирования достаточно удобная штука, но со своими особенностями и перед его использованием следует хорошо все продумать, чтобы не оказалось, что при эксплуатации минусы вдруг перевесят плюсы.
В обсуждениях многие упоминали и планировали развертывание сервера лицензирования 1С, поэтому мы решили отдельным материалом осветить все достоинства и недостатки такого решения.
Начнем с того, что правильно такое решение называется именно Сервис лицензирования, а не Сервер лицензирования, но второй вариант давно прижился и его также можно использовать, только следует понимать, что речь идет об одном и том же.
Сервис лицензирования представляет отдельную серверную инсталляцию в кластере серверов, которая содержит только одноименную службу (Назначение функциональности в терминах 1С) и не требует для запуска отдельной серверной лицензии.
Сервис лицензирования может выдавать серверные и клиентские многопользовательские лицензии, последние всегда выдаются только на сеанс, вне зависимости от режима подключения клиента.
Минимальные требования к сервису лицензирования – два ядра и 4 ГБ оперативной памяти, хотя последнее требование на наш взгляд несколько завышено.
Также следует помнить, что сервис лицензирования не работает с HASP-ключами и не может привязать лицензию к такому ключу.
Еще один важный момент – сервис лицензирования не работает с клиентскими подключениями, а выдает лицензии только серверу (серверам), который в свою очередь может выдать ее клиенту.
Версия платформы и разрядность сервиса лицензирования должна совпадать с версией платформы или разрядностью рабочих серверов.
При запуске на одном узле нескольких экземпляров сервера 1С:Предприятие при получении лицензии из сервиса лицензирования вам потребуется отдельная лицензия на каждый запущенный экземпляр.
При этом на сервисе лицензирования также потребуется установить и запустить на разных портах несколько экземпляров сервера 1С.
При работе терминального сервера лицензия будет выдаваться не на терминальный сеанс, допускающий неограниченное число сеансов 1С:Предприятие, а на каждый сеанс 1С.
Как видим, особенностей у сервиса лицензирования хватает и подходить к его развертыванию следует взвешенно, проанализировав все плюсы и минусы относительно собственной ситуации.
Так, например, в однозначные плюсы можно записать возможность изменять параметры компьютера или виртуальной машины сервера 1С без необходимости повторной активации лицензии.
А в столь же однозначные минусы то, что теперь два экземпляра сервера на одном узле потребуют две серверных лицензии вместо одной.
Что касается клиентских лицензий, то здесь ситуация не меняется, за исключением терминального сервера.
Но есть и плюс, при наличии нескольких серверов в кластере они могут использовать для выдачи клиентам общий пул лицензий, что исключает ситуации, когда на сервере А лицензии закончились, а на сервере Б их еще с избытком.
Ну и не забываем о том, что наличие сервиса лицензирования совсем не означает необходимости переноса всех лицензий на него. Вы можете перенести только те лицензии, которые считаете нужным, а другие оставить непосредственно на серверах.
Если сильно упростить ситуацию, то поиск лицензии будет происходить следующим образом: сначала на клиенте, потом на сервере, потом на сервисе лицензирования.
В заключение хочется сказать, что сервис лицензирования достаточно удобная штука, но со своими особенностями и перед его использованием следует хорошо все продумать, чтобы не оказалось, что при эксплуатации минусы вдруг перевесят плюсы.
👍20❤2🥱1
Как мы пишем код с ИИ и чем это отличается от написания кода руками
Вопрос привлечения ИИ к выполнению повседневных задач волнует многих коллег, но вместе с тем есть превратное представление, что если специалист использует ИИ, то специалист он так себе, а то. что выдала ИИ – что-то низкопробное, не совсем качественное. То ли дело руками.
Поэтому мы решили рассказать, как писали последний скрипт, который опубликовали вчера, какую роль там сыграла нейросеть и как вообще изменился процесс разработки.
Разработка, несомненно, процесс творческий, но само написание кода – это еще та рутина. Потому как кроме основной логики вам приходится писать обертки, проверки, сервисные функции и т.д. и т.п. что долго, нудно и вообще претит творческому духу.
И это когда вы знаете язык на уровне, что команды сами от пальцев отлетают, а если вы пишете на языке время от времени, то постоянно будете спотыкаться о синтаксис, конструкции, допускать простые ошибки, забывать приводить типы и т.д и т.п.
В общем, вроде бы и понятно, что делать, но постоянно какие-то сложности. А время идет. Кроме того, еще и отладить надо, проверив разные режимы работы и выяснив почему только что все работало, а тут, неожиданно сломалось.
По кратким прикидкам работа с данным скриптом заняла бы не менее полного рабочего дня. Но был бы это принципиально иной результат, более качественный? Несомненно, все так, только есть тонкость, как в старом анекдоте: не в лотерею, а в карты, не Волгу, а три рубля, не выиграл, а проиграл.
ИИ сейчас уже пишет код гораздо более качественно, чем человек. Вы можете открыть скрипт и посмотреть, он написан по всем правилам PowerShell, с правильным форматированием и синтаксисом, что обеспечивает ему отличную читабельность.
Он прокомментирован и поэтому если вы даже неуверенно читаете сам код, то без труда поймете общую структуру.
Он документирован, прямо в самом начале написано, что это за скрипт, что делает, как его запускать и подключать. Для чего нужны какие файлы и т.д. и т.п. Также документированы все файлы настроек , в которых написано, для чего они нужны и как их заполнять.
И именно это обычно является слабым местом программиста человека, редко кто удосуживается писать подробные комментарии и краткую документацию прямо в коде. Обычно это оставляют «на потом», что обозначает чаще всего «никогда».
Также весь скрипт обернут проверками практически везде, с понятными сообщениями пользователю, если что-то пошло не так или чего-то не хватает. Нет нужной зависимости – напишем, не нашли конфигурационных файлов – тоже, максимально понятно русским языком, да еще и в лог занесем.
Это тоже слабое место программиста человека, потому как тоже долго, нудно, муторно. Проще предположить, что все нужное есть, а если нет – невелика беда, ну выкинет скрипт ошибку, делов то.
Надо ли говорить, что такой подход полностью порочен и не добавляет программисту очков в глазах пользователя, у которого вчера работало. а сегодня полотно каких-то заморских ругательств пишет.
А особенно порадуются ваши коллеги, которые будут это все эксплуатировать и, скажем, при переносе на новую систему будут долго пытаться понять, что происходит, вместо того чтобы получить понятное сообщение об отсутствии какой-то зависимости.
ИИ все это делает сразу и не напрягаясь, ее даже не нужно об этом просить, для нее это стиль разработки по умолчанию.
Плюс меняется сам процесс, теперь вы сосредоточены именно на творческой части процесса и занимаетесь именно тем, чем и хотели – разработкой и отладкой, а рутину в виде написания кода буквами берет на себя ИИ.
В нашем случае ИИ накосячил только в одном месте – формировании строки подключения к ibcmd и это было единственное место, где мы просто молча поправили руками и сказали сетке – правильно вот так, прими к сведению.
Но там вопрос тонкий, ошибся он на том, что очень скупо освещено в официальной документации и курсе только те, кто в курсе.
Ну и результат мы получили всего часа за полтора, большую часть времени посвятив отладке и проверке при различных вводных.
Вопрос привлечения ИИ к выполнению повседневных задач волнует многих коллег, но вместе с тем есть превратное представление, что если специалист использует ИИ, то специалист он так себе, а то. что выдала ИИ – что-то низкопробное, не совсем качественное. То ли дело руками.
Поэтому мы решили рассказать, как писали последний скрипт, который опубликовали вчера, какую роль там сыграла нейросеть и как вообще изменился процесс разработки.
Разработка, несомненно, процесс творческий, но само написание кода – это еще та рутина. Потому как кроме основной логики вам приходится писать обертки, проверки, сервисные функции и т.д. и т.п. что долго, нудно и вообще претит творческому духу.
И это когда вы знаете язык на уровне, что команды сами от пальцев отлетают, а если вы пишете на языке время от времени, то постоянно будете спотыкаться о синтаксис, конструкции, допускать простые ошибки, забывать приводить типы и т.д и т.п.
В общем, вроде бы и понятно, что делать, но постоянно какие-то сложности. А время идет. Кроме того, еще и отладить надо, проверив разные режимы работы и выяснив почему только что все работало, а тут, неожиданно сломалось.
По кратким прикидкам работа с данным скриптом заняла бы не менее полного рабочего дня. Но был бы это принципиально иной результат, более качественный? Несомненно, все так, только есть тонкость, как в старом анекдоте: не в лотерею, а в карты, не Волгу, а три рубля, не выиграл, а проиграл.
ИИ сейчас уже пишет код гораздо более качественно, чем человек. Вы можете открыть скрипт и посмотреть, он написан по всем правилам PowerShell, с правильным форматированием и синтаксисом, что обеспечивает ему отличную читабельность.
Он прокомментирован и поэтому если вы даже неуверенно читаете сам код, то без труда поймете общую структуру.
Он документирован, прямо в самом начале написано, что это за скрипт, что делает, как его запускать и подключать. Для чего нужны какие файлы и т.д. и т.п. Также документированы все файлы настроек , в которых написано, для чего они нужны и как их заполнять.
И именно это обычно является слабым местом программиста человека, редко кто удосуживается писать подробные комментарии и краткую документацию прямо в коде. Обычно это оставляют «на потом», что обозначает чаще всего «никогда».
Также весь скрипт обернут проверками практически везде, с понятными сообщениями пользователю, если что-то пошло не так или чего-то не хватает. Нет нужной зависимости – напишем, не нашли конфигурационных файлов – тоже, максимально понятно русским языком, да еще и в лог занесем.
Это тоже слабое место программиста человека, потому как тоже долго, нудно, муторно. Проще предположить, что все нужное есть, а если нет – невелика беда, ну выкинет скрипт ошибку, делов то.
Надо ли говорить, что такой подход полностью порочен и не добавляет программисту очков в глазах пользователя, у которого вчера работало. а сегодня полотно каких-то заморских ругательств пишет.
А особенно порадуются ваши коллеги, которые будут это все эксплуатировать и, скажем, при переносе на новую систему будут долго пытаться понять, что происходит, вместо того чтобы получить понятное сообщение об отсутствии какой-то зависимости.
ИИ все это делает сразу и не напрягаясь, ее даже не нужно об этом просить, для нее это стиль разработки по умолчанию.
Плюс меняется сам процесс, теперь вы сосредоточены именно на творческой части процесса и занимаетесь именно тем, чем и хотели – разработкой и отладкой, а рутину в виде написания кода буквами берет на себя ИИ.
В нашем случае ИИ накосячил только в одном месте – формировании строки подключения к ibcmd и это было единственное место, где мы просто молча поправили руками и сказали сетке – правильно вот так, прими к сведению.
Но там вопрос тонкий, ошибся он на том, что очень скупо освещено в официальной документации и курсе только те, кто в курсе.
Ну и результат мы получили всего часа за полтора, большую часть времени посвятив отладке и проверке при различных вводных.
👍27🔥5💯2❤1⚡1
Как читать таблицу маршрутизации в Windows
Как показывает практика, маршрутизация - одна из наиболее сложных тем для начинающих администраторов. Хотя, казалось бы, берем таблицу маршрутов, там все написано.
Но не все умеют правильно читать и понимать там написанное.
Следует запомнить несколько простых правил.
1️⃣ Сначала в таблице ищется маршрут с самой узкой маской. Минимальная маска - 255.255.255.255, максимальная - 0.0.0.0.
2️⃣ Если маршрутов несколько, то берется маршрут с самой маленькой метрикой.
3️⃣ После того, как маршрут найден, следует определить интерфейс выхода, который должен быть расположен в одной из непосредственно присоединенных сетей, т.е. быть доступен на канальном уровне.
Посмотрим на картинку внизу. Если мы хотим пропинговать сами себя, т.е. 192.168.233.154, то для этого сразу будет найден кратчайший маршрут в непосредственно присоединенной сети (зеленый). On-link обозначает непосредственно присоединенную сеть.
Если мы хотим обратиться к ПК из своего сегмента. то нам подойдет маршрут с более широкой маской /24 (желтый).
А если ни одного подходящего маршрута нет? Тогда нам следует использовать маршрут по умолчанию или нулевой маршрут 0.0.0.0/0.
Смотрим, таких маршрутов сразу два. Какой из них использовать? Тот у кого меньше метрика, т.е. на интерфейса 10.20.0.101 Он тоже доступен без маршрутизации.
Если же этого маршрута не будет (отключим VPN), то заработает верхний маршрут с метрикой 25. Но там стоит адрес шлюза - 192.168.233.2. Поэтому идем дальше и ищем маршрут уже для этого адреса.
Поиск такого маршрута производится только среди непосредственно присоединенных сетей и очень скоро мы снова находим нужный маршрут, который помечен желтым.
☝️ Поэтому всегда, составляя и анализируя маршруты, помним - любой маршрут должен приводить в непосредственно присоединенную сеть, иначе он работать не будет.
Почему? Да потому что IP - это 3-й уровень модели OSI - сетевой и нельзя просто так передавать IP-пакеты между ПК. Для того, чтобы это сделать, мы должны опуститься на канальный уровень и вложить их в датафреймы.
А потом еще ниже, на физический, но так глубоко мы копать не будем.
А канальный уровень - это непосредственно присоединенная сеть и только так. Это же ответ на многие вопросы типа: я написал маршрут, а он не работает. В этом случае всегда смотрим, а можем ли мы по нему достичь непосредственно присоединенной сети или нет.
Как показывает практика, маршрутизация - одна из наиболее сложных тем для начинающих администраторов. Хотя, казалось бы, берем таблицу маршрутов, там все написано.
Но не все умеют правильно читать и понимать там написанное.
Следует запомнить несколько простых правил.
1️⃣ Сначала в таблице ищется маршрут с самой узкой маской. Минимальная маска - 255.255.255.255, максимальная - 0.0.0.0.
2️⃣ Если маршрутов несколько, то берется маршрут с самой маленькой метрикой.
3️⃣ После того, как маршрут найден, следует определить интерфейс выхода, который должен быть расположен в одной из непосредственно присоединенных сетей, т.е. быть доступен на канальном уровне.
Посмотрим на картинку внизу. Если мы хотим пропинговать сами себя, т.е. 192.168.233.154, то для этого сразу будет найден кратчайший маршрут в непосредственно присоединенной сети (зеленый). On-link обозначает непосредственно присоединенную сеть.
Если мы хотим обратиться к ПК из своего сегмента. то нам подойдет маршрут с более широкой маской /24 (желтый).
А если ни одного подходящего маршрута нет? Тогда нам следует использовать маршрут по умолчанию или нулевой маршрут 0.0.0.0/0.
Смотрим, таких маршрутов сразу два. Какой из них использовать? Тот у кого меньше метрика, т.е. на интерфейса 10.20.0.101 Он тоже доступен без маршрутизации.
Если же этого маршрута не будет (отключим VPN), то заработает верхний маршрут с метрикой 25. Но там стоит адрес шлюза - 192.168.233.2. Поэтому идем дальше и ищем маршрут уже для этого адреса.
Поиск такого маршрута производится только среди непосредственно присоединенных сетей и очень скоро мы снова находим нужный маршрут, который помечен желтым.
☝️ Поэтому всегда, составляя и анализируя маршруты, помним - любой маршрут должен приводить в непосредственно присоединенную сеть, иначе он работать не будет.
Почему? Да потому что IP - это 3-й уровень модели OSI - сетевой и нельзя просто так передавать IP-пакеты между ПК. Для того, чтобы это сделать, мы должны опуститься на канальный уровень и вложить их в датафреймы.
А потом еще ниже, на физический, но так глубоко мы копать не будем.
А канальный уровень - это непосредственно присоединенная сеть и только так. Это же ответ на многие вопросы типа: я написал маршрут, а он не работает. В этом случае всегда смотрим, а можем ли мы по нему достичь непосредственно присоединенной сети или нет.
1👍33❤4
О жизни, о молодежи
Молодежь нынче принято ругать, мол не такие, такие-сякие, вот мы в их годы… Явление это не новое и тянется с поколения в поколение. Особенно на сломе технологических укладов. Проблему отцов и детей поднимали еще древние философы, не говоря о классиках русской литературы.
И вот сегодня произошел интересный случай, который заставил меня совсем по-другому посмотреть на нашу молодежь. Дело было вечером, я собирался выйти пройтись по магазинам, так как закончилось кофе и так, по мелочи к завтраку.
Уже собираясь выходить, зашел на кухню и услышал из открытого окна поток отборного мата откуда-то из-под подъезда. Голос незнакомый, всех местных «буйных» после третьего стакана я знаю. Матерился он не на кого-то конкретно, а просто так, в темноту.
А у нас, в Белгороде, уличное освещение отсутствует как класс еще с осени, после первых прилетов по энергетике. И тут из темноты, со стороны спортивной площадки выезжает паренек лет 13-14 и вежливо, на вы спрашивает: дедушка, а чего вы тут материтесь?
Я напрягся и приготовился быстро выбежать, если события примут неприятный оборот, мало-ли, но дед явно не ожидал такого и включил заднюю, мол это не он и вообще, чего они к нему пристали.
Постепенно со всего двора к подъезду собрались дети от младшего школьного возраста до подростков лет 15-16 и начали дружно деда стыдить.
Дед агрессии не проявлял, и я решил без спешки досмотреть все до конца. А аргументы у паренька были увесистые, но обращался он к делу предельно вежливо, на вы. Другие подтверждали, что сами слышали, как дед тут матерился.
- Ну что, вам не стыдно, тут же дети? А у вас самого внуки есть? Перед ними не стыдно?
Здесь я мысленно пареньку поаплодировал. Никакого хамства, хиханек-хаханек, все строго, по существу, культурно, вежливо.
- А если вас кто на телефон снимет и в интернет выложит?
При этом я отметил, что деда никто на телефон не снимал.
Когда я вышел на улицу деда уже застыдили и он спокойно сидел на лавке, а ребята снова переместились на площадку.
Дед незнакомый, сильно выпивший, но на алкаша не похож. Ну перебрал в выходной, бывает. Спрашивает какой это дом, какая улица. Видно, что потерялся в пространстве, а тут и до беды недалеко.
Спускаюсь с порожек, окликаю ребят, мол никто деда не знает? Никто. Ну вы, говорю, проследите за ним, хорошо…
И тут они меня снова удивили, мол не беспокойся дяденька, мы деда сфотали, в чат класса сбросили, спросили кто знает. Узнаем кто такой, проследим. Мы же не дураки, тоже все прекрасно понимаем, выпил дед лишнего.
Через полчаса я вернулся, деда не было, ребята все еще сидели на площадке, увидев меня первые доложили, мол в порядке все, его внучка в параллельном классе с какой-то из присутствующих девочек учится, пришли, забрали.
Молодежь нынче принято ругать, мол не такие, такие-сякие, вот мы в их годы… Явление это не новое и тянется с поколения в поколение. Особенно на сломе технологических укладов. Проблему отцов и детей поднимали еще древние философы, не говоря о классиках русской литературы.
И вот сегодня произошел интересный случай, который заставил меня совсем по-другому посмотреть на нашу молодежь. Дело было вечером, я собирался выйти пройтись по магазинам, так как закончилось кофе и так, по мелочи к завтраку.
Уже собираясь выходить, зашел на кухню и услышал из открытого окна поток отборного мата откуда-то из-под подъезда. Голос незнакомый, всех местных «буйных» после третьего стакана я знаю. Матерился он не на кого-то конкретно, а просто так, в темноту.
А у нас, в Белгороде, уличное освещение отсутствует как класс еще с осени, после первых прилетов по энергетике. И тут из темноты, со стороны спортивной площадки выезжает паренек лет 13-14 и вежливо, на вы спрашивает: дедушка, а чего вы тут материтесь?
Я напрягся и приготовился быстро выбежать, если события примут неприятный оборот, мало-ли, но дед явно не ожидал такого и включил заднюю, мол это не он и вообще, чего они к нему пристали.
Постепенно со всего двора к подъезду собрались дети от младшего школьного возраста до подростков лет 15-16 и начали дружно деда стыдить.
Дед агрессии не проявлял, и я решил без спешки досмотреть все до конца. А аргументы у паренька были увесистые, но обращался он к делу предельно вежливо, на вы. Другие подтверждали, что сами слышали, как дед тут матерился.
- Ну что, вам не стыдно, тут же дети? А у вас самого внуки есть? Перед ними не стыдно?
Здесь я мысленно пареньку поаплодировал. Никакого хамства, хиханек-хаханек, все строго, по существу, культурно, вежливо.
- А если вас кто на телефон снимет и в интернет выложит?
При этом я отметил, что деда никто на телефон не снимал.
Когда я вышел на улицу деда уже застыдили и он спокойно сидел на лавке, а ребята снова переместились на площадку.
Дед незнакомый, сильно выпивший, но на алкаша не похож. Ну перебрал в выходной, бывает. Спрашивает какой это дом, какая улица. Видно, что потерялся в пространстве, а тут и до беды недалеко.
Спускаюсь с порожек, окликаю ребят, мол никто деда не знает? Никто. Ну вы, говорю, проследите за ним, хорошо…
И тут они меня снова удивили, мол не беспокойся дяденька, мы деда сфотали, в чат класса сбросили, спросили кто знает. Узнаем кто такой, проследим. Мы же не дураки, тоже все прекрасно понимаем, выпил дед лишнего.
Через полчаса я вернулся, деда не было, ребята все еще сидели на площадке, увидев меня первые доложили, мол в порядке все, его внучка в параллельном классе с какой-то из присутствующих девочек учится, пришли, забрали.
👍59🔥24❤10🤮2🤡1