На моей домашней машине вот уже 7 лет работает пара дисков, объединенная в soft raid1. И вот на днях один диск в зеркале наконец начал сыпаться. Появился повод переустановить систему с нуля и начать использовать шифрование, которое 7 лет назад не было задействовано. В процессе гугления о состоянии дел в конфигурации LUKS поверх mdadm я вышел на статью сравнивающей производительность zfs vs mdadm/ext4. А потом нашел другую статью с тестированием производительности зашифрованных дисков использующих LUKS и zfs. Согласно обеим статьям zfs демонстрирует весьма неплохую производительность и я решил попробовать ее в деле.

Две разные системы (win + linux) на одной аппаратной базе - реальность. В этом нет ничего нового или инновационного (на данный момент времени), но если требуется максимальная производительность гостевой системы, то не обойтись без проброса реальных устройств в виртуальную машину. Проброс сетевых карт, usb-контроллеров (etc) экстраординарных особенностей не несёт, а вот попытка "шаринга" ресурсов видеокарты и процессора вполне может принести некоторое количество проблем.

Итак, а для чего, собственного говоря, городить системы с полнофункциональным использованием ресурсов GPU и CPU? Самый простой и очевидный ответ - игры (широко известный факт - если не большинство, то очень многие, написаны под ОС Windows). Другой вариант - полноценное рабочее место с возможностью запуска требовательных приложений (например, CAD-софта), быстрым бэкапом (скопировать файл ВМ куда проще, чем создавать полную копию HDD/SSD) и опцией полного контроля сетевого трафика гостевой системы.

Скрипты на Bash. Как много в этом слове. Любому разработчику рано или поздно приходится их писать. Почти никто не скажет "да, я люблю писать bash-скрипты", и поэтому этой теме уделяют мало внимания.

Я не буду пытаться сделать из вас эксперта в Bash, а просто покажу минимальный шаблон, который поможет сделать ваши скрипты более надежными и безопасными.

В 2021 году все еще многие компании используют файловые серверы для совместной работы, поэтому остается актуальным вопрос разграничения доступа на общих ресурсах.

Как правильно организовать доступ к файловым ресурсам описано в Best Practices от Microsoft, в том числе и в документе Windows Productivity for IT Professionals из Microsoft Resource Kit. В Сети можно найти множество статей на русском языке по организации файлового сервера, в том числе и на Хабре.

Например, вот эти:

Аспирин от настройки прав на файловом сервере
Правила хорошего тона для дизайна разрешений на файловых серверах

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

А что делать, если необходимо, раздать доступ на ресурсе, в котором 200 папок? И таких ресурсов у вас несколько штук.

Приветствую всех читателей статьи!

Данная статья будет полезна как новичкам в IT сфере, так и неопытным системным администраторам/ сетевым инженерам. Здесь затрагиваются понятия и принцип работы технологии NAT, ее значение в наше время, виды и создание с конфигурированием в программе-симуляторе Cisco Packet Tracer.

Попытаемся спрогнозировать запросы на обслуживание оборудования, по истории запросов в Service Desk.

Имеется однотипное оборудование компании, в разных регионах, например, станки, или сервера. Имеется департамент сервиса, который выполняет заявки на обслуживание серверов: почистить, заменить деталь, обновить софт. Имеется Service Desk система, в которой ведется история этих заявок, за несколько лет. Специалист, выполнивший обслуживание сервера, заполняет и закрывает заявку в системе Service Desk.

Исходные данные: датасет со следующими полями:

Статья по мотивам доклада «Эффективный DevOps / Максим Залысин (Ситимобил)» с конференции DevOps Live 2020 команды Онтико.

В этой статье попытаемся понять, как изменились процедуры обслуживания индексов для таблиц Microsoft SQL Server в современных условиях: при размещении файлов данных и журнала транзакций на SSD-дисках, многократном увеличении числа процессорных ядер и в условиях, когда оперативная память сервера стала измеряться Терабайтами.Действительно, мир стал другим. С тех пор как появились первые версии SQL Server, многое изменилось и многие методики, основанные на старых компьютерных ресурсах, работают уже не так эффективно, как прежде, когда без них невозможно было обойтись. Одной из таких методик, которая с давних пор воспринимается чуть ли не «серебряной пулей», а на деле превратилась в миф, является обязательная дефрагментация индексов, если в данные индекса достаточно часто вносятся изменения. Цель статьи развеять этот миф.

В своей документации, Майкрософт обращает наше внимание на то, что не стоит выполнять обслуживание индексов, не убедившись, что это принесёт пользу. Вот цитата:

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

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

О простых и продвинутых способах запуска PostgreSQL в Docker: добавляем healthcheck, ставим на мониторинг, настраиваем параметры.

Несколько больших нод или много маленьких?

Управление Kubernetes-кластером - это не та задача, где есть одно правильное решение на все случаи жизни. Есть много способов оптимизации кластера и главное здесь - это обеспечение стабильной и отказоустойчивой работы приложений.

Как site-reliability и DevOps инженерам вам нужно иметь в виду потребности приложений, которые будут запускаться в кластере, и учитывать различные факторы при его проектировании.

Выбор правильного размера ноды критичен для разработки масштабируемых приложений. Иметь множество маленьких нод или несколько больших - это две крайности. Для кластера, которому нужно всего 24Gb памяти и 12 CPU лучше выбрать 12 машин по 1-CPU/2GB или две по 6-CPU/12GB ?

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

20 марта 2013 года на конференции PyCon 2013, Соломон Хайкс (CEO компании dotCloud) выступил с пятиминутной презентацией The future of Linux Containers. В ней широкой общественности впервые была представлена внутренняя разработка компании dotCloud под названием Docker, а спустя несколько дней ее исходный код был выложен в открытый доступ. Хотя технологии LXC и Aufs, на которых была основана первая версия Docker существовали и активно использовались уже порядка пяти лет, но именно появление Docker послужило началом стремительного роста и эволюции систем контейнеризации, что кардинально преобразило многие процессы разработки и деплоймента программного обеспечения.

Этой статьей я собираюсь начать небольшой цикл посвященный изучению развития исходного кода Docker на протяжении нескольких лет. В первой части мы посмотрим на то, что представлял собой код на момент создания git репозитория датированного январем 2013 года. Тогда исходный код Docker (за исключением тестов) состоял всего из шести файлов общим объемом ~600 строк кода, написанных на языке Go. Это больше походило на библиотеку/api, функционал которой состоял лишь в создании, удалении, запуске и остановке контейнеров. Мы разберем принцип работы и даже сможем запустить с ее помощью подготовленный контейнер. 

Во второй части мы перенесемся на несколько месяцев вперед - в март 2013, когда докер был представлен на конференции PyCon. На тот момент он уже обладал практически всеми знакомыми нам функциями. А в третьей части я постараюсь рассмотреть переход Docker с LXC на собственную разработку, произошедший годом позже.

К старту курса о Fullstack-разработке на Python мы подготовили сокращённый перевод опроса StackOverflow среди почти 83 000 людей, без малого 70 % из них — профессиональные разработчики. Опрос проводился с 15 июня по 25 мая, облачные платформы в нём впервые выделены из платформ в целом, также добавлен раздел о том, с какими языками, платформами, фреймворками и т. д. людям хотелось бы работать. Конечно, вы найдёте в опросе информацию о зарплатах и образовании. Подробности, как всегда, под катом.

Евгений Тетеньчук из DINS расскажет о компонентах TICK, разберет альтернативы и покажет возможный путь миграции в другие решения. Участие бесплатное, но нужно зарегистрироваться. 

Подробная программа и информация о спикерах — под катом.

Источник

Команда Kubernetes as a Service в Mail.ru Cloud Solutions перевела статью, в которой автор помогает найти причины ошибок в Kubernetes, если вы совсем не понимаете, куда нужно смотреть. Далее текст от лица автора.

Kubernetes — непростая платформа, особенно когда что-то пошло не так и нужно срочно найти и устранить возникшую проблему. В основном трудности объясняются сложностью самой системы и отсутствием подробных сообщений об ошибках. Ситуация усугубляется еще и огромным количеством «шестеренок» в потоке оркестрации контейнеров — при том что для представления этого потока используется всего лишь несколько состояний. Например, есть как минимум шесть возможных причин, по которым под может зависнуть в состоянии ContainerCreating или CrashLoppBackOff.

Мы активно работаем с Kubernetes уже более трех лет и за это время составили длинный список сложных и в то же время трудно диагностируемых проблем. Большинство из них можно отнести к одной из трех категорий:

1. Зависание пода в состоянии ContainerCreating.
2. Ошибка CrashLoopBackOff и периодический перезапуск контейнера.
3. Проблемы с сетью.

Краткий обзор

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

«Мне 34, и я 10 лет работаю в ИТ. Первый компьютер я увидел в каталоге OTTO, мне тогда было 5 лет, я жил в Германии. Это был ATARI. Меня сразу заинтриговал принцип его работы — мы вводим информацию и получаем ожидаемый результат на выходе. Круто, но события 90-х годов отодвинули мечту на много лет. И вот, наконец, в 2001-м у меня появился свой ПК. К слову, операционную систему я переустановил через 2 недели использования. С этого всё началось. Пока сверстники играли в ходилки и стрелялки, я методом научного тыка изучал устройство Windows 98. Потом вышла XP, был Dial-up в 56 kbps и долгие часы скачивания разнообразных программ, форумы, журналы CHIP и первый дистрибутив Alt Linux на CD.   

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

С такими мыслями я «собрал пожитки» и отправился прочь из зоны комфорта на поиск новых знаний в области инструментов концепции DevOps. Кто ищет ― тот найдёт, сказал я сам себе и спустя 10 минут заполнял анкету на поступление в DevOps-школу в EPAM»...  

В этой статье представители EPAM и студенты DevOps-школы расскажут о том, как построено обучение, для кого школа и зачем туда идти.  

Гитхаб экшены, как я познавал ci/cd

   Всем Алоха. Все слышали про ci/cd, про то что он должен быть в каждой компании и то что он упрощает нам жизнь. У всех свой ci/cd. 

   Кто-то предпочитает Jenkins. Особенно если у вас куча микросервисов, команд и процессов, то при помощи Дженкинса можно достаточно гибко настроить ci/cd в компании. Кто-то использует GitLab actions и для каждого репозитория настраивает свои пайплайны и процессы. Достаточно удобно и просто настраиваемый механизм сборки и доставки артефактов на стенды. Не чуть не хуже GitHub actions. Это было открытием для меня что в GitHub появился такой функционал, о котором мы поговорим позже. Ну и конечно всеми «любимый» скриптовый ci/cd. Пачка скриптов, которые нужно выполнить в определенной последовательности чтобы собрать и задеплоить артефакты. Есть ещё так сказать хэнд мэнуал ci/cd. Но это особый вид извращения, с которым не пожелаю столкнуться никому. В котором нужно собрать артефакты у себя на машине и по какому нить ридми выполнять команды в терминале, лазить по ssh смотреть, что все копировалось, перезапускать сервисы и другие развлечения. 

    Передо мной стояла задача спроектировать и написать новый сервер для проекта. Изначально я закидывал джарники на сервак руками, чтобы проверить работоспособность и настроить сервер. Хэнд мэнуал деплой. В какой то момент меня это начало бесить и я задумался об автоматизации этого процесса. Как вы понимаете девопса или того кто шарит в этом у меня под рукой в компании не оказалось. Очень круто, если у вас есть такой человек. У меня был выбор сделать скрипт деплой, чего я искренне не хотел, потому что в целом не любитель копаться в терминале и скриптах, когда этого можно избежать. Поднять дженкинс и настроить там джобы и пайплайны. Вариант оч классный для большой компании, а мне нужен деплой лишь одного сервера, а не тысячи микросервисов. Да и чего таить, знаний как настраивать дженкинс с нуля у меня было чуть меньше чем ноль. 

Сложно выбрать какую-то дату, к которой бы можно приурочить этот текст. То ли август, когда родился Аркадий Натанович, то ли апрель, когда родился Борис Натанович. А уж подстраиваться под даты публикаций дело совсем неблагодарное: даже в наиболее провластный период своего творчества отношения с властью и её цензурой у братьев плохо складывались. Публикую тут в феврале, потому что ... почему бы и нет.

Да, я ноунейм из интернета, очень начинающий редактор, просто делюсь своим мнением. И вот спонтанно, под настроение, решил порассуждать о самом, пожалуй, влиятельном писательском дуэте нашей фантастики.