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

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

Две рефлектограммы одной и той же трассы на разных длинах волн, открытые в программе-viewer'е

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

И ещё. По моему личному мнению, эта статья для массового читателя покажется более скучной и сложной, чем предыдущие, потому что одно дело посмотреть на сварку волокон, а другое дело — копаться в каких-то скучных графиках. :) Но тем не менее знать это необходимо тем, кто работает с оптоволокном.

Часть 1 здесь
Часть 2 здесь
Часть 3 здесь

Осторожно: много картинок, трафик!

Привет хабр. Сегодня я хочу рассказать о необычном явлении, которое я наблюдал в результате эксперимента. Скажу сразу ничего общего с ИТ и объяснений с научной точки зрения не будет.
А будет «качер», ёмкость с водой, испорченные лампочки и любопытство познать новое! Кому стало интересно – прошу, заходите, будет весело.

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

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

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

Load average может представлять собой непростой для понимания показатель производительности сервера. В этой статье мы попытаемся дать некоторое представление о том, что означают те величины, которые можно найти в выводе команды «top» и в других linux-командах. В статье, также объясняются параметры специфичные для виртуального хостинга, которые обычно не отображается в стандартном выводе команды top.

Я работаю с программными моделями центральных процессоров в составе полноплатформенного симулятора. Занятие это, конечно же, очень интересное — приходится иметь дело с технологиями интерпретации, двоичной трансляции, виртуализации (об этом я уже писал здесь). Однажды моё внимание привлёк тот факт, что значительную часть времени я вожусь над единственной, казалось бы, не самой вычислительно интенсивной инструкцией. Причина в том, что типов процессоров существует много, и все они во многом похожи; однако при этом критически важно очень точно представлять различия между ними.
В этой статье я описываю, зачем и как процессоры умеют сообщать о своих возможностях, и как к этому вопросу подошли разные производители. В её продолжении я расскажу об эволюции и особенностях инструкции CPUID для Intel IA-32, например, почему её описание занимает в Intel SDM [1] около 40 страниц.

Эти приемы были описаны во внутреннем проекте компании Google «Testing on the Toilet» (Тестируем в туалете — распространение листовок в туалетах, что бы напоминать разработчикам о тестах).
В данной статье они были пересмотрены и дополнены.

Для кого эта статья

Данная статья составлена по материалам практики по курсу операционных систем в Академическом университете . Материал готовился для студентов, и ничего сложного здесь не будет, достаточно базового знания командной строки, языка C, Makefile и общих теоретических знаний о файловых системах.

Весь материал разбит на несколько частей, в данной статье будет описана вводная часть. Я коротко расскажу о том, что понадобится для разработки в ядре Linux, затем мы напишем простейший загружаемый модуль ядра, и наконец напишем каркас будущей файловой системы — модуль, который зарегистрирует довольно бесполезную (пока) файловую систему в ядре. Люди уже знакомые (пусть и поверхностно) с разработкой в ядре Linux не найдут здесь ничего интересного.

    В этой статье я рассмотрю по шагам подготовку к использованию Samba4 в роли контроллера домена вкупе с дополнительным файловым сервером так же на базе Samba4. Что в итоге мы получим? Два настроенных сервера с samba4, первый в роли domain controller, второй в роли member server с файлами пользователей. Функционирования этой связки я добивался около месяца, за сим, не поделится конечным рецептом просто не имею права…



    Немного предыстории: в компании используется файловый сервер на базе samba3.6 с LDAP Backend, который содержит список всех пользователей и групп с правами доступа. Права доступа на каталоги выставляются с помощью xattr_acl (Extended file attributes), в LDAP хранится список пользователей с соответствием группам доступа. Собственно требуется переехать с этой инфраструктуры на samba4…

В этой короткой заметке я хочу рассказать о том, как подготовить тестовый стенд для работы с мультикастом.
Для меня самого эта задача была очень актуальной при подготовке девятого выпуска Сетей Для Самых Маленьких.
Хочется ведь не просто увидеть циферки в консоли, а посмотреть видео.

В качестве эмулятора мы будем использовать GNS.

Поясняющее наглядное видео.



Для примера мы возьмём вот такую сеть:



Здесь R1 олицетворяет собой IP-сеть, редуцированную до одного узла — это в общем-то не имеет значения.
Главный вопрос: что будет на месте мультикастового сервера и клиента.

Это продолжение серии из двух постов, в которых я рассказываю о построении VDI-решения для крупной российской софтверной компании. Первый пост здесь.

Немного математики

Опираясь на описанную в предыдущем посте теорию, проведем расчеты:

Одновременно от 6 до 9 пользователей VDI могут использовать одно физическое ядро CPU. Для упрощения возьмем среднюю цифру — 7 пользователей.

Согласно требованиям заказчика необходимо обеспечить работу 700 пользователей по VDI с расширением до 1000.

Не секрет, что CCIE является одной из наиболее влиятельных и значимых сертификаций в IT. Грядет очередное большое обновление, и мне захотелось осветить его основные изменения.

1. Введение в ODR – On-Demand Routing

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

• Статическая маршрутизация – маршруты добавляются вручную администратором.
• Динамическая маршрутизация – администратор настраивает протоколы динамической маршрутизации.

Но в каждом из этих случаев есть недостатки:

• Основным недостатком статической маршрутизации является необходимость переконфигурации устройств при изменении структуры сети или адресов.
• Основными недостатками динамической маршрутизации недостатками являются: дополнительная нагрузка на каналы и понижение безопасности.

В принципе нельзя сказать что эти недостатки существенны в современных условиях. Навряд ли сети будут переконфигурироваться часто, современные каналы связи достаточно широки, что бы без проблем передавать относительно небольшой трафик, генерируемый протоколами маршрутизации. И даже проблему внешних динамических IP адресов, получаемых от провайдера можно решить путем использования технологии динамического DNS.
Но на самом деле есть еще один недостаток, общий для обоих вариантов – вам нужен обслуживающий персонал в каждой точке, где стоит маршрутизатор. Тот, кто будет прописывать статические маршруты или настраивать протокол динамической маршрутизации.
Именно для таких случаев компания Cisco разработала проприетарный протокол ODR, который по сути даже не является протоколом динамической конфигурации, это расширение еще одного проприетарного протокола – CDP. С помощью протокола ODR маршрутизаторы могут обмениваться маршрутной информацией специфическим образом (в результате объем передаваемой информации существенно меньше, чем у других протоколов динамической маршрутизации), и при этом конфигурация всех маршрутизаторов сети не требуется. Настраивается только один маршрутизатор – основной маршрутизатор компании, все остальные маршрутизаторы не требуют вообще никакой настройки маршрутизации, ни статической, ни динамической.
Таким образом, получается, что ODR не обладает выше указанными недостатками:

• Объем передаваемых данных минимален, по сравнению с протоколами протоколов динамической маршрутизации.
• Требуется минимальная конфигурация на одном маршрутизаторе.

Этот пост — первая часть из серии рассказов о том, как можно относительно несложно сделать своими руками радиоуправляемый выключатель полезной нагрузки.
Пост ориентирован на новичков, для остальных, думаю, это будет «повторение пройденного».


Примерный план (посмотрим по ходу действия) ожидается следующий:

1. Hardware выключателя
2. Тестирование и подготовка
3. Software выключателя
4. «Центр управления»

Уже более 3 лет наша команда занимается разработкой такого важного компонента сети оператора как PCRF. Policy and Charging Rules Function (PCRF) – решение для управления политиками обслуживания абонента в сетях LTE (3GPP), позволяющее в реальном времени назначать ту или иную политику, принимая во внимание сервисы, подключенные у абонента, его местонахождение, качество сети в данном месте в данный момент, время суток, объем потребленного трафика и т.д. Под политикой в данном контексте подразумевается доступный абоненту набор сервисов и параметры QoS (качества обслуживания). Анализируя соотношение цена-качество для различных продуктов в данной области от разнообразных поставщиков, мы приняли решение разрабатывать свой продукт. И вот уже более 2 лет, наш PCRF успешно работает на коммерческой сети компании Yota. Решение полностью софтовое, с возможностью устанавливать даже на обычные виртуальные сервера. Работает в коммерции на Red Hat Linux, но в целом возможна установка и под другие Linux-системы.

Часть вторая

Прелюдия

Сегодня я расскажу вам как я создавал бюджетное отказоустойчивое iSCSI хранилище из двух серверов на базе Linux для обслуживания нужд кластера VMWare vSphere. Были похожие статьи (например), но мой подход несколько отличается, да и решения (тот же heartbeat и iscsitarget), используемые там, уже устарели.

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

Вводные

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

В качестве гипервизора был выбран vSphere, как наиболее устоявшийся и законченый продукт, а в качестве протокола — iSCSI, как не требующий дополнительных финансовых вливаний в виде коммутаторов FC или FCoE. С опенсурсными SAS таргетами довольно туго, если не сказать хуже, так что этот вариант тоже был отвергнут.

Осталось хранилище. Разные брендовые решения от ведущих вендоров были отброшены по причине большой стоимости как их самих по себе, так и лицензий на синхронную репликацию. Значит будем делать сами, заодно и поучимся.

В качестве софта было выбрано:

• Debian Wheezy + LTS ядро 3.10
• iSCSI-таргет SCST
• DRBD для репликации
• Pacemaker для управления ресурсами кластера и мониторинга
• Подсистема ядра DM-Crypt для шифрования (инструкции AES-NI в процессоре нам очень помогут)

В итоге, в недолгих муках была рождена такая несложная схема:

Создание пакетов или packet crafting — это техника, которая позволяет сетевым инженерам или пентестерам исследовать сети, проверять правила фаерволлов и находить уязвимые места.
Делается это обычно вручную, отправляя пакеты на различные устройства в сети.
В качестве цели может быть брандмауэр, системы обнаружения вторжений (IDS), маршрутизаторы и любые другие участники сети.
Создание пакетов вручную не означает, что нужно писать код на каком-либо высокоуровневом языке программирования, можно воспользоваться готовым инструментом, например, Scapy.

Scapy — это один из лучших, если не самый лучший, инструмент для создания пакетов вручную.
Утилита написана с использованием языка Python, автором является Philippe Biondi.
Возможности утилиты практически безграничны — это и сборка пакетов с последующей отправкой их в сеть, и захват пакетов, и чтение их из сохраненного ранее дампа, и исследование сети, и многое другое.
Всё это можно делать как в интерактивном режиме, так и создавая скрипты.
С помощью Scapy можно проводить сканирование, трассировку, исследования, атаки и обнаружение хостов в сети.
Scapy предоставляет среду или даже фреймворк, чем-то похожий на Wireshark, только без красивой графической оболочки.
Утилита разрабатывается под UNIX-подобные операционные системы, но тем не менее, некоторым удается запустить ее и в среде Windows.
Эта утилита так же может взаимодействовать и с другими программами: для наглядного декодирования пакетов можно подключать тот же Wireshark, для рисования графиков — GnuPlot и Vpython.
Для работы потребуется права суперпользователя (root, UID 0), так как это достаточно низкоуровневая утилита и работает напрямую с сетевой картой.
И что важно, для работы с этой утилитой не потребуются глубокие знания программирования на Python.

Это продолженеие статьи о помехоустойчивом кодировании, которая очень долго лежала в черновиках. В прошлой части нет ничего интересного с практической точки зрения — лишь общие сведения о том, зачем это нужно, где применяется и т.п. В данной части будут рассматриваться некоторые (самые простые) коды для обнаружения и/или исправления ошибок. Итак, поехали.

Вступление.

Прежде всего стоит сказать, что такое Код Хэмминга и для чего он, собственно, нужен. На Википедии даётся следующее определение:

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

Другими словами, это алгоритм, который позволяет закодировать какое-либо информационное сообщение определённым образом и после передачи (например по сети) определить появилась ли какая-то ошибка в этом сообщении (к примеру из-за помех) и, при возможности, восстановить это сообщение. Сегодня, я опишу самый простой алгоритм Хемминга, который может исправлять лишь одну ошибку.