После создания нового диска появляется желание проверить его скорость. Например, линейную.

dd if=/dev/xvdb of=/dev/null bs=1M count=1000         
1048576000 bytes (1.0 GB) copied, 1.29269 s, 811 MB/s  

dd if=/dev/zero of=/dev/xvdb  bs=1k  count=1000
10240000 bytes (10 MB) copied, 24.3481 s, 421 kB/s

Обескураживающие цифры, правда? При этом если повторить эксперимент, то скорость чтения упадёт, а скорость записи вырастет до положенных 60-150Мб/с.

Причина этого — в copy-on-write режиме работы блочных устройств, обслуживаемых blktap в Xen Cloud Platform.

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

Архитектура

У нас разделены аккаунтинг и биллинг, или, на бюрократическом языке, система автоматического учёта и система автоматического расчёта.

Система автоматического учёта (аккаунтинг) считает, сколько какой компонент виртуальной машины потребил ресурсов. А кому эта виртуальная машина принадлежит, какие деньги брать и т.д. — это не его головная боль. Более того, он даже про слово «облако» ничего не знает.

Работает он очень близко к гипервизору. Например, значения процессорного времени и памяти читаются напрямую из гипервизора, а счётчики дисков и трафика — из счётчиков производительности блочных (сетевых) устройств в dom0.

Заметим, что аккаунтиг ничего не знает и про «сегодня», «вчера», «за неделю» и т.д. — он просто считает счётчик. Который растёт вверх неубывающе за всё время жизни машины. Рядом, правда, добавлен ещё один сервис, который собирает данные для графиков, но в процессе списания денег никак не участвует.

… или что такое на самом деле 'raid edition' для жёстких дисков

Немного теории

Существуют две стратегии поведения НЖМД при обнаружении ошибки:

• standalone/desktop — пытаться прочитать до последнего. Это ощущается как «тормозящий винт», который всё-таки работает, если это единичный сбой, то «затупило, но прошло», плюс характерный перестук перекалибрующихся головок.
• raid — отваливаться тут же. Это ощущается как «внезапно была ошибка диска но потом mhdd и т.д. НИЧЕГО НЕ НАШЁЛ ЧТО МНЕ ДЕЛАТЬ».

Статегии очевидным образом различаются по предназначению — десктоп лучше протупит, но ошибку не выдаст, в рейде есть запасной винт, и терпеть минутные тормоза на чтении никто не имеет никакой возможности. Не получилось прочитать? Читаем с запасных винтов, помечаем весь винт как сбойный, начинаем ресинк, а диск потом отправят в утилизатор. Возможно, незаслуженно, но нечего икать на ответственной должности.

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

Расшифровка названия

Возможность управления поведением диска при ошибках называется очень и очень путанно: SCT ERC. Это расшифровывается как SCT Error Recovery Control. SCT в свою очередь название общего протокола SMART Command Transport. SMART в свою очередь расшифровывается как Self-Monitoring, Analysis and Reporting Technology, таким образом, полная расшифровка SCT ERC звучит так: Self-Monitoring, Analysis and Reporting Technology Command Transport Error Recovery Control (выдохнули).

Новости одной строкой:

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

Консоль

Скроллинг

Мы добавили историю вывода на экран. Теперь, «уползший» с экрана текст доступен некоторое время для просмотра. Перемещаться по истории можно кнопками Shft-PgUp, Shift-PgDown. Размер буфера выбран так, чтобы на загрузившейся машине можно было увидеть сообщения до перезагрузки. В дальнейшем появятся ещё дополнения к этой истории. Традиционно, реализация этого функционала — в нашем репозитории на гитхабе. На картинке — история загрузки машины. Виден вывод машины до перезагрузки и первые шаги новой загрузки.


Кстати, раз мы заговорили о консоли, вот несколько интересных возможностей консоли, о которых, возможно, не все знают.

Alt-SysRq

Существует некоторая путаница с тем, закончились IPv4, «вот-вот закончатся» или их ещё очень много.

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

Источник всея IP

Те, кто скажет, что источником IP-адресов является IANA, будут немного неправы. IANA, как и RIR'ы, подчиняются полиси, которую принимают консенсусом среди всех участников интернета. (Для тех, кто не знает, кто есть IANA и RIR, см ниже). Сообщество приняло в качестве протокола IPv4, вместе с его «номером сети» и «широковещательным адресом», концепцией агрегации маршрутов, сегментами серых и мультикаст-адресов и т.д. Именно оно (сообщество) определяет правила выделения адресов и политику фильтрации. И именно оно делегировало IANA приличную порцию адресов. (не все /0, но весьма большой кусок — больше /1). И уже адреса из него раздаёт IANA.

Кто такие «члены сообщества»? Чисто формально — любые люди. На практике: «любые люди» — это люди, способные связно говорить о процедурах выделения (allocation) и назначения (assignation) адресов, понимающие как реализуется multihomed, и что такое нетранзитный частный атрибут у комьюнити. То есть, де-факто, сетевые администраторы и noc'и крупных операторов связи, крупных хостеров, очень крупных организаций и т.д. Эти сообщества (несколько произвольно) разделены по регионам. Наше (европейское) сообщество называется RIPE, расшифровку на французском я не помню. Таких сообществ несколько, и они определяют во-первых локальные правила выделения адресов, во-вторых, глобальные правила.

Новость вкратце: С 1 августа мы меняем цены. Значительные изменения: цена исходящего трафика уменьшается с 1 рубля за Гб до 64 копеек за Гб, дисковые операции повышаются с 3 рублей за миллион до 5 рублей за миллион. Остальные цены меняются незначительно, объяснение «зачем» ниже. Кроме того, мы переводим официальные цены с величины «цены за час» на «цену за секунду». Официальные цены приведены в конце статьи, в таблице ниже они даются с дробными копейками и в расчёте «за час» для возможности сравнения со старыми ценами.

Ресурс	Старые цены	Новые цены
Процессорное время	1 рубль за час	↓ 90 копеек за час
Оперативная память	50 копеек за Гб*ч	↑ 57,6 копейки за час
Дисковые операции	3 рубля за миллион	↑ 5 рублей за миллион
Прочитанные/записанные данные	10 копеек за Гб	10 копеек за Гб
Хранение данных	5 рублей за Тб*ч	↓ 4.5 рубля за Тб*ч
Входящий трафик	20 копеек за Гб	↓ 16 копеек за Гб
Исходящий трафик	1 рубль за Гб	↓ 64 копейки за Гб

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

IOPS'ы дороже, трафик дешевле

Не будем скрывать, нагрузка на диски — самая неприятная для облака проблема. Исходя из концепции облака «за ваши деньги — хоть на голове пляшите», мы скорректировали цены так, чтобы получать достаточную компенсацию за неудобную для нас нагрузку.

Снижение цены трафика — шаг навстречу крупным клиентам, для которых расходы на исходящий трафик иногда достигают 50% от общих расходов.

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

В этот раз мы публикуем библиотеку сериализации в JSON типов данных Erlang, авторства si14 под BSD 2-clause license. Те проекты, для которых написана эта библиотека, ещё не готовы (ждите анонсов к осени), но библиотека уже стала вполне самостоятельной и может применяться в множестве других случаев. Традиционно, рассчитываем на кооперацию в совершенствовании, с интересом услышим о применении в других проектах.

В дебри Erlang'а

В отличие от многих динамических языков, в Erlang'е есть опциональные аннотации типов для функций и record'ов. На текущий момент они используются минимум 3 утилитами: edoc (формирует документацию из исходников; пример получаемой документации можно увидеть, например, здесь), что более важно, dialyzer (анализирует существующую информацию о типах и сообщает об ошибках несоответствия типов, в том числе несоответствия декларируемого и выведенного типов) и PropEr (система автоматической генерации тестов на основании информации о типах и декларативно задаваемых свойств функций). Использование этих деклараций стало правилом хорошего тона, поэтому почти все качественные проекты на Erlang'е имеют их. Нельзя ли использовать информацию о типах где-либо ещё?

JANE

В процессе разработки одного из проектов возникла идея: почему бы не использовать существующую информацию о типах прямо в JS

Новость одной строкой: клиентам стали доступны графики потребления ресурсов виртуальными машинами в облаке.

История создания

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

Несколько скриншотов этой статистики даже появлялось у нас в блоге.

Мы уже почти были готовы опубликовать её для клиентов, как, вдруг, обнаружился прискорбный факт: при буквально нескольких сотнях машин 8-ядерного Xeon'а не достаточно для того, чтобы посчитать её всю.

Причина была в наивной математике. Источники статистики для каждой виртуальной машины:

Как и было обещано, мы выпускаем под LGPL нашу библиотеку эмуляции эмулятора терминала linux, которую мы используем для показа консолей виртуальных машин в облаке. Называется она, соответственно, pyte (PYthon Terminal Emulator).

По нашим собственным оценкам, покрытие «текстового» функционала console_codes приближается к 100% (от 80 до 90%, как подсказывают пессимисты из числа оппортунистов среди разработчиков).

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

Зато реализованы все остальные сложные функции, такие, как блокировка регионов экрана для записи, скроллинга, управление режимами переноса строк, правильная обработка атрибутов при различных видов удаления текста и т.д. — всё то, что нужно существующим приложениям, таким как nano, adom (на картинке фрагмент ESC-кодов и получающегося изображения как раз из ADOM'а), vim, emacs, mc, aptitude, dialog, yast2 и т.д. для полноценной отрисовки.

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

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

История создания

RIPE (европейский интернет-регистратор, организация, распределяющая IP-адреса) проводит два обучающих курса в Санкт-Петербурге.

RIPE NCC LIR Training Course

Проходит: 21.07.2011
Место проведения: Санкт-Петербург, в отеле Holiday Inn (адрес см ниже)
Темы:

• The Internet Registry (IR) System
• Exercise: RIPE and the RIPE NCC
• The Policy Development Process
• Exercise: First Day at Work as an LIR Contact
• The RIPE Database
• IPv4 Resources
• Exercise: Making Assignments
• Other Resources: AS Numbers & IPv6
• RIPE NCC Services
• Exercise: Slogan

RIPE NCC IPv6 Training Course

Проходит: 22.07.2011
Место проведения: Санкт-Петербург, в отеле Holiday Inn (там же, адрес ниже)
Темы:

• The Registry System
• IPv4?
• Exercise: Business Case
• IPv6 Basics
• Exercise: Addressing Plan
• Getting it
• Deploying
• Exercise: Deployment Challenges

Расписание и место

Новость одной строкой: теперь клиенты могут изменять параметры MOD из панели управления.

Давным-давно в нашем mod-server'е была реализована возможность управления параметрами выделения памяти. Это было реализовано на уровне самого сервера и параметров базы данных.

… Но этого не было в веб-интерфейсе. Самые настойчивые клиенты просили изменить настройки — и мы их меняли вручную. Глупо, да?

Наконец-таки, мы исправили ситуацию — настройки MOD-сервера стали доступны клиентам. Большая их часть применяется «на ходу» и не требует перезагрузки или приостановки обслуживания.

Принцип работы Memory-on-Demand

(сомневался сюда писать или в системное администрирование)

Я обнаружил, что в интернете очень мало (и не очень внятно) объяснено, как mdadm работает с общими (глобальными) дисками горячей подмены. В заметке я опишу, что это такое, и объясню, почему shared hotspare не отмечены в /proc/mdstat как общие, а вместо этого выглядят как вполне себе локальные.

Что такое hot-spare?

(Я пишу не для новичков, так что галопом по европам)
Если массив обладает избыточностью и один из его дисков вышел из строя, то существует возможность восстановить избыточную информацию на резервный диск. Если диск добавляется в массив руками (админу пришло письмо о сбое, он прочитал письмо, проснулся/оделся, приехал на работу, вынул сбойный диск, вставил запасной, добавил его в массив, дал команду на восстановление избыточности), то такой диск называется cold-spare. Просто «запасной диск».

Если же в сервере есть простаивающий диск, на который осуществляется восстановление избыточности сразу после сбоя любого из дисков массива, то такой диск называется hot-spare. Главное достоинство — оно отребилдится (восстановит избыточность) даже если админ письмо прозевал или не успел вовремя приехать.

Локальные hot-spare

Бувально в тот момент, когда я (не очень успешно) вычитывал ошибки и опечатки в предыдущем посте, bobry предложил обсудить, как сделать в консоли историю (которая, Shift-PgUp).

Очевидным методом сделать что-то связанное с терминалами — посмотреть, как сделано у других и сделать так же. В процессе изучения этого мы обратили внимание на интересную особенность: некоторые программы, показывая содержимое, восстанавливают экран до запуска приложения (mc, vim, nano, less и т.д.). Кроме того, при их запуске исчезает (в xterm/gnome-terminal) скролл-бар.

Для изучения «каким образом» было решено остановиться на MC, как самом старинном (и не зависящем от ncurses) приложении.

Далее идёт роматичная история о том, как mc делает toggle_panel() с большим количеством цитат из исходного кода.

Заодно, читатель сможет посмотреть, как выглядит процесс «посмотри в исходниках».

            Если посадить тысячу мартышек за тысячу пишущих машинок, то за тысячу лет они напишут эмулятор терминала. — вместо эпиграфа.

Извините фальстарт, это не я, это андроидный смартбук.

Когда мы только запускали облако, первой проблемой было «как нам получить консоль». Штатный механизм XCP поразумевает, что консоль рисуется с помощью VNCTerm, а желающий её увидеть должен сначала пойти в XenAPI, получить там session-id консоли, пойти на порт консоли, передать session-id, получить RFB, завёрнутый в HTTP, развернуть HTTP, вынуть RFB (он же VNC), отдать её локальному рендереру VNC (VNC-клиенту или java-апплету с тем же функционалом). При этом консоль закрывалась (сессия рвалась) при каждой перезагрузке виртуальной машины. Она рвалась даже при миграции виртуальной машины. Другими словами, это была технология, которая подразумевала «глянул одним глазком, починил ssh/iptables и забыл». Неудобно, медленно, сложно. Выкатывать такое в продакт совсем не хотелось.

И я залез в дебри serial-howto, console-howto и ещё несколько ужасных документов, рассказывающих о том, как правильно нужно конфигуриовать прерывания на ISA плате у мультикарт, а так же специфику настройки linux-2.2 для работы с оными. Параллельно изучалось устройство консоли в зене (внимательный читатель мог даже заметить, когда именно я более-менее разобрался в этом вопросе — я писал на хабре краткий обзор того, что происходит с консолью).

После этого пришла мысль: нужно писать своё, потому что готового чужого хорошего нет.

Сначала мы хотели взять хотя бы готовые компоненты и сделать из них своё. Я помню до сих пор ту замечательную схему, в которой мы планировали сохранять в БД вывод anyterm'а, делать двойное туннелирование последовательного порта с использованием UDP… Выглядело это, мягко скажем, неприглядно.

Потом пришла в голову мысль выпилить anyterm. Для этого нужно было посмотреть, как работают терминалки. Это было очень забавно и поучительно (желающие могут изучить исходный текст PuTTY). Главной проблемой в этом изучении было то, что они много рисуют на экран. Прямо в процессе обработки ввода. Отделить специфику DC от, собственно, того, что является консолью, было сложно.

Через некоторое время мы пришли к идее «нам нужен свой эмулятор терминала».
Задача казалась относительно простой, пока мы не прикоснулись к бездне, именуемой «escape-коды и типы терминалов...».

Пишущие машинки

Итак, в начале была пишущая машинка. В какой-то момент возникло желание совместить телеграф с пишущей машинкой. Так возник телетайп
Разумеется, инженерам, создававшим телетайп, не было никакого резона делать все с нуля. Они просто приделали коды к каждой клавише пишущей машинки. После некоторых боёв в стиле MS VS Netscape, был создан стандарт html5 на коды для оных машинок, то бишь телетайпов. Если мне память не изменяет, то это ASCII, где предусмотрены все комбинации клавиш, характерные для американской пишущей машинки. Включая код BELL, который, кстати, должен вовсе не делать BEEP, а делать «дзыньк», ибо у пишущих машинок был именно колокольчик, а не спикер.

Предыдущая часть: habrahabr.ru/post/119407

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

Карьера сисадмина

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

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

Как только у вас появилось свободное время — вы снова стоите на концептуальном перепутье. Вы можете просто продолжать работать администратором, и делать это долгое время. У вас будет копиться опыт, ваше резюме будет становиться всё менее и менее крикливым, а ожидаемая сумма будет постепенно расти, у вас появится сколько-то настоящих success story… Так может продолжаться неограниченно долго. Более того, про эту стадию сисадминства чуть ли не легенды складывают «я всё настроил и могу заниматься чем хочу», «чем больше админ работает, тем хуже он», «хороший админ должен бездельничать, пока сервера работают» и т.д.

Но что дальше? А дальше изменения могут быть только с вашей стороны. Вы можете либо продолжать стихийное развите «под потребности работодателя», либо начать выстраивать собственную специализацию. При этом «развитие под потребности работодателя» у вас будет идти спорадически, т.к. бизнесу в моменты затишья ничего не нужно нового от ИТ, нужно, чтобы оно продолжало работать. Для настоящего развития нужно смотреть глубже, и свободное время тратить не на исполнение обязанностей офисного планктона, а на обучение (если вы думали, что пройдя путь от аникея до «крутого админа» мучения с книжками/мануалами закончатся — не мечтайте).

Потребности бизнеса

Кстати, о потребностях бизнеса (поскольку деньги платит именно он, то именно он и определяет ситуацию на рынке труда)

У нас на работе как-то был довольно жаркий спор о том, считать ли python 2.7 стабильным. Итоги спора и сам вопрос я оставляю в стороне, а тут я хочу изложить и систематизировать определённые мысли о реальных программах, которые сильно противоречат миру Фон Неймана и Тьюринга.

Мир, в котором работают программисты — это мир правильного кода. Разумеется, в нём есть бесчисленные ошибки, но эти ошибки подлежат исправлению. Если это ошибки в чужом коде, который не исправить, они подлежат документированию и учитыванию в своём коде. Но ошибка — это всегда повод её найти и устранить.

Мир же системного администрирования другой. Тут код, который «какой есть, такой есть». Невозможно даже мельком прочитать исходные тексты всех пакетов даже для самой маленькой и скромной установки. 300+ Мб линукса, исходные коды основных библиотек и программ… Оно в принципе необозримо. Можно знать конкретные программы, конкретные места программ — но невозможно знать весь runtime, всё программное окружение, из которого состоит ОС.

И оно полно ошибок. Можно сколько угодно рассуждать про прелести мат. доказательств кода, но это совершенно не поможет, если сбой обнаружится в проприентарном драйвере видеокарты (казалось бы, и при чём тут сервер?) или сетевой карты с TCP offload.

К проблеме ПО есть совсем другой подход — подход сугубо практический. У нас есть априори багованный код, который иногда работает как мы ожидаем этого.

И вот вокруг этого «иногда» и строится вся концепция «стабильности» и product-ready.

Для виртуальных машин в облаке Селектел была добавлена консоль. Она доступна в панели управления во вкладке «консоль».

Вот ключевые отличия от примитивного «вот вам VNCterm, разбирайтесь сами»:

• текстовая консоль — малый трафик
• никаких плагинов (flash/java и т.д.) — работает средствами html/ajax.
• консоль можно смотреть одновременно с нескольких браузеров.
• консоль переживает перезагрузку и миграцию
• консоль можно увидеть на выключенной машине (ввод не работает по понятным причинам — но можно увидеть как машина выключалась).
• Копипейст — выделить мышкой и скопировать, вставка Shift-Ins или Cmd-V для маков.
• Переживает миграцию виртуальной машины без разрывов и неприятностей.
• Автоматическая регуляция скорости работы — при интерактивной работе скорость увеличивается, на простаивающей машине — снижается.
• Практически 100% поддержка linux_console — цвета, скроллинг и т.д. Проверены на работоспособность все основные программы — ncurses-based, mc, vim, emacs, nano, пачка консольных игрушек — adom, nethack, тетрис и т.д. Не поддерживается только экзотика вида «загрузить шрифты», «управление VESA-режимами и т.д.».
• Поддержка большинства комбинаций клавиш (зависит от браузера) — Ctrl-комбинации, Alt-комбинации, функциональные кнопки и т.д.
• Полная поддержка unicode (настолько, насколько его поддерживает ваш браузер), как минмум, псевдографика и русский язык работают без каких-либо проблем.

Чего не сделано:

Предыдущая часть: habrahabr.ru/post/118966

В этой части: как закончить быть эникеем и стать системым администратором.

Итак, допустим, вы работаете эникеем. Возможно, уже вторую или даже третью работу. Допустим, вы восприняли всерьёз мой совет читать по 20-30 айтишных книжек в год и прочитали за прошедшие два года аж 4 книги. У вас обширный экспириенс общения с пользователями, вы перестали бояться бить в бубен, а удачно посылать пользователей вы научились лучше админа. (Не в этом ли причина третьей по счёту работы?).

В «завершении карьеры» есть два важных фактора: куда уйти и как уйти.

Я сейчас скажу очень важную вещь, её многие, работающие на «младших должностях» не понимают, а на самом деле это очень важно:

Не портите себе карму

Не увольняйтесь внезапно.

Никакой серверной части. Только JS: полноценный эмулятор компьютера с линуксом на борту.

bellard.org/jslinux
(внимание, только хром и FF4)

Я долго с ним игрался — это не имитация, линукс ведёт себя как настоящий линукс — компилированные программы работают, ошибки в них вызывают segmentation fault, повреждение корневой файловой системы вызывает бурю возмущения в dmesg и т.д.


dd показывает при работе с памятью более чем приличную производительность — более 40 мб/с (не забываем, что это эмулятор, и что это JS в вашем браузере!).

Я никогда не думал, что мы доживём до подобного.

… А теперь начинается оргия:

* С использованием локального хранилища мы можем организовать диски (каждый key-value соответствует одному сектору).
* С использованием web-socket мы можем создать паравиртуализированный драйвер сети с выходом на железный машрутизатор и получить нормальную сеть.
* С использованием существующих технологий (NUMA, DRBD, corosync) можно организовать вычислительный кластер из браузеров.

(Кстати, показывать консоль в этом случае не обязательно — вы запускаете виртуальную машину у клиента в бэкграунде, виртуальная машина присоединяется к кластеру, начинает считать, по её аварийному завершению — закрытию браузера — кластер автоматически переконфигурируется).

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

Никто не мешает создать паравиртуализированный драйвер видео с помощью canvas, у вас есть webGL, для которого можно написать свой вариант cuda и получить довольно мощную акселерацию вычислений…

Ну и финал — запуск хрома внутри эмулируемой виртуальной машины.

Итак, эмуляция дошла до браузеров…

Предыдущая часть: habrahabr.ru/post/118475

В этой части: подробнее о жизни эникейщика: как устроиться, чем заниматься, чего избегать, к чему стремиться.

Я откладываю вопрос о «будущем сисадмина» на следующие части — сейчас я сфокусируюсь на том, как начинается карьера. Повторю, опытным администраторам всё это будет казаться либо обидным, либо очевидным — но я достаточно посмотрел за эту весну на людей, которые пытаются «вскочить в индустрию», но у них не получается. Именно для них этот цикл статей. (Я не ощущаю себя достаточно умным, чтобы рассказывать про будущее карьеры для людей, у которых опыта, возможно, больше, чем у меня).

Вступление

Примерно до середины 2000ых было два пути стать системным администратором: через путь эникейщика и через профильное высшее образование (обычно, в всякого рода институтах связи). Первое давало много опыта, второе — довольно много знаний (из которых большая часть не нужна). Сейчас появился третий — всякого рода «курсы системного администрирования», которые, реально, тлен и прах (если судить по тому, что знают и умеют те, кто их закончил).