Поговорим про поддержку .NET на IntelliJ платформе. После прочтения вы сами решите: реальность ли?

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

Прочитав статью Базы данных в онлайн играх и особенно комменты к ней, я в очередной расстроился от мысли, что многие разработчики меняют БД в своём проекте, пытаясь этой сменой решить свои проблемы, не исчерпав, однако, всех возможностей, предоставляемой заменяемой БД. Я принимаю участие в работе над проектом, БД которого характеризуется:

• Количеством транзакций порядка 5'000 — 10'000 в секунду
• Объемом примерно в 100ГБ (который бодро растёт)
• Примерно равным количеством операций на чтение/запись
• Преимущественно мелкими транзакциями

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

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

В этой заметке я опишу методы увеличения производительности линуксового маршрутизатора. Для меня эта тема стала актуальна, когда проходящий сетевой трафик через один линуксовый маршрутизатор стал достаточно высоким (>150 Мбит/с, > 50 Kpps). Маршрутизатор помимо роутинга еще занимается шейпированием и выступает в качестве файрволла.

Написано по следам публикации Большие потоки трафика и управление прерываниями в Linux

В нашей городской сети более 30 тысяч абонентов. Суммарный объем внешних каналов — более 3 гигабит. А советы, данные в упомянутой статье, мы проходили еще несколько лет назад. Таким образом, я хочу шире раскрыть тему и поделиться с читателями своими наработками в рамках затрагиваемого вопроса.

В заметке описываются нюансы настройки/тюнинга маршрутизатора и NAT-сервера под управлением 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 в процессоре нам очень помогут)

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

История

Внедрение Linux в ПриватБанке началось в 2007 году. За это время был пройден большой путь и хотелось бы поделиться с сообществом своим опытом внедрения. На данный момент мы достигли следующих показателей: более 36500 рабочих мест с ОС Linux в 4000 отделений, расположенных в 5 странах.
В 2007 году за основу был взят ASPLinux 11.2. Со временем для альтернативы были выбраны другие дистрибутивы — Fedora, openSUSE, Ubuntu. Позже стала очевидной необходимость создания собственного дистрибутива и системы управления рабочими станциями. Разработка началась в январе 2012 года. Для основы был выбран Ubuntu 12.04 LTS с рабочим окружением Gnome Classic (no effect). Основные аргументы: Ubuntu — самый распространённый десктопный дистрибутив последних лет; обширное комьюнити, где проще найти решение возникающих проблем; именно его в качестве основы внедрения выбрал Google, много примеров внедрения в государственных и муниципальных учреждениях Германии, Франции. Выбор системы управления остановился на Puppet.
В июне 2012 года стартовал переход и к январю 2013 на корпоративную ОС были переведены уже около 95% ПК. Такая скорость перехода обусловлена тем, что сотрудники уже имели опыт работы в Linux.

Основные задачи, которые удалось решить благодаря текущему внедрению:

• cущественная экономия ресурсов при поддержке ОС на рабочих местах сотрудников;
• поддержание программного обеспечения в актуальном состоянии;
• возможность оперативного применения критических обновлений (до 1 часа на всех ПК);
• cбор и анализ статистической информации о парке ПК и периферии;
• создание системы проактивной реакции на сбои (Event Manager).

Дальше более детальное описание компонентов нашей реализации.

Добрый день, дорогие хабражители.

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

Вот несколько необычных фактов о языке C#, о которых знают лишь немногие разработчики.

1. Индексаторы могут использовать params параметры

Мы все знаем, как обычно выглядят индексаторы x = something["a"], а так же код необходимый для его реализации:

public string this[string key]
 {
   get { return internalDictionary[key]; }
 }

Но знали ли вы, что для доступа к элементам вы можете использовать params параметры x = something["a", "b", "c", "d"]?
Просто напишите ваш индексатор следующим образом:

4 апреля мы провели первую FailOver Conference — конференцию, целиком и полностью посвященную отказоустойчивости сайтов и их бесперебойной работе.

Целый день, более 7 часов, мы слушали доклады от разработчиков и архитекторов облачных сервисов, системных администраторов хостинг-провайдеров, опытных DBA, обсуждали их, спорили…

Тема оказалась очень важной и востребованной — более 1200 человек зарегистрировались на онлайн-трансляцию.

Конечно, сложно сразу «переварить» такой большой объем информации. К чему-то хочется вернуться позже, попробовать применить к конкретному проекту. Именно поэтому один из самых часто звучащих вопросов как из зала, так и в онлайне (в твиттере): «А будут ли опубликованы материалы?»

Да, конечно! Мы публикуем и презентации, и видео докладов, и с удовольствием делимся ими с вами!

Автор: Piotr Siwczak

Когда я разрабатывал свою первую инфраструктуру OpenStack, я с трудом находил информацию о том, как следует распределять многочисленные ее компоненты по оборудованию. Я изучил множество документов, в том числе справочник по архитектуре Rackspace (который ранее был размещен по ссылке referencearchitecture.org, но сейчас, похоже, эта ссылка устарела). Я также просмотрел проектные схемы в документации OpenStack. Должен признать, что тогда у меня были только базовые знания о том, как взаимодействуют компоненты, поэтому я остановился на достаточно простой схеме: один “управляющий узел”, который включал все компоненты, в том числе API-сервисы, nova-scheduler, Glance, Keystone, базу данных и RabbitMQ. Под управление узла я поместил ферму “рабочих лошадок” — вычислительных узлов. Я также организовал три сети: частную (для трафика с фиксированным IP-адресом и управления серверами), общедоступную (для трафика с динамическим IP-адресом) и для хранения (для трафика по протоколу iSCSI сервиса nova-volume).

Когда я начал работать в Mirantis, я значительно изменил свой подход. Я понял, что все мои идеи по созданию фермы выделенных вычислительных узлов с одним или двумя управляющими узлами, были неверными. С одной стороны, мой подход был хорош в плане разделения компонентов, но на практике мы можем с легкостью смешивать и компоновать рабочие компоненты без перегрузки OpenStack (например, сервис nova-compute с сервисом nova-scheduler на одном узле). Оказывается в OpenStack “управляющий узел” и “вычислительный узел” могут иметь разные значения в зависимости от того, как гибко распределены компоненты OpenStack.

В общем, можно предположить, что в каждой установке OpenStack должны быть как минимум три типа узлов (и, возможно, четвертый), которые описал мой коллега Олег Гельбух:

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

Если интересно как это работает прошу под кат.

Здравствуйте.

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

Что необходимо?

Для загрузки системы нужны три компонента: ядро, initramfs и корневая файловая система.
Ядро и initramfs мы передадим по TFTP, а корневую файловую систему — по iSCSI.

iSCSI-таргеты

Для Ubuntu возможно использовать различные iSCSI-таргеты. Вот неполный их список:

• ISCSI Enterprise Target — одна из самых старых реализаций iSCSI-таргета на Linux. Насколько мне известно, жива и здравствует, однако требует установки (в Ubuntu) через DKMS и совсем лёгкого дребезга бубнов. На opennet.ru есть рабочий HOWTO, применимый и к более поздним версиям ОС (Precise)
• SCSI Target Framework (STGT/TGT) — реализация iSCSI-таргета, портированная из BSD-систем. В отличии от IET, позволяет использовать не только iSCSI, но и другие родственные технологии (такие, как, например, SRP). К сожалению, код STGT в части iSCSI в линуксе работает в userspace. Как следствие, производительность получается где-то в районе плинтуса.
• SCST — новая реализация универсального таргета для Linux. По заявлениям разработчиков обладает массой преимуществ и фишек. В ядро не включена, для установки требует патчей исходников ядра и продолжительного зубодробительного секса. По слухам, мила, прекрасна и похожа на сакуру. Когда-то давно ее использовали, например, в Оверсан-Скалакси (их опыт вкратце описан на хабре). Пакеты для Ubuntu перестали поддерживаться около полутора лет назад, в SVN есть некоторая активность, то есть проект жив и здравствует. Кстати, разработчики — русские парни :)
• LIO — Linux Unified Target, универсальная система, реализующая iSCSI, SRP, FCoE и несколько других вариантов экспорта устройств в сеть. Официально включена в ядро и является стандартным таргетом, начиная с версии 2.6.38. К ней есть определенные претензии в плане того, что на официальном сайте активно продвигается проприетарная сборка, обладающая большим функционалом, но оставим вопли RMS.

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

Сынишку, в силу его годовалого возраста, подарок не сильно впечатлил, а позволять бросать сложное электронное устройство на пол и отрывать этому устройству уши мне было жалко, и все шло к тому, чтобы убрать подарок на полку до лучших времен, однако мой взгляд пал на одну надпись на красочной упаковке…

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



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

Каждый из нас выбирает для себя наиболее удобную среду разработки. Многие пользуются отдельной IDE, несколькими открытыми консолями, отдельным браузером, множеством прочих сторонних инструментов. Я же придерживаюсь принципа — все должно быть милимастично и просто конфигурируемо. Tmux позволяет сделать очень удобную рабочую среду для программиста.


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

Здравствуйте.

Этот топик открывает цикл статей по использованию системы управления конфигурацией Puppet.

Что такое система управления конфигурацией?

Предположим, что у вас есть парк серверов, выполняющих различные задачи. Пока серверов мало и вы не растёте, вы легко настраиваете каждый сервер вручную. Устанавливаете ОС (может быть, автоматизированно), добавляете пользователей, устанавливаете софт, вводя команды в консоль, настраиваете сервисы, правите конфиги ваших любимых текстовых редакторов (nanorc, vimrc), выставляете на них одинаковые настройки DNS-сервера, устанавливаете агент системы мониторинга, настраиваете syslog для централизованного сбора логов… Словом, работы довольно много и она не особенно интересна.

В своей предыдущей статье я вкратце коснулся темы создания High Availability решения на основе демона heartbeat. Однако, как выяснилось, что-то сложнее чем 2-х узловой кластер на нем делать не так уж удобно. Изучение проблемы вывело меня на след проекта Pacemaker. Его-то мы сейчас в кратце и рассмотрим.

Приветствую, Хабражители.

Досталась мне в «наследство» ИТ инфраструктура бюджетной организации, очень мощная, с заделом по производительности, но абсолютно не управляемая. Что имеем:

• 4000 хостов в сети
• Коммутаторы уровня доступа: Cisco Catalyst 35xx (~2500 портов)
• В центре оптический коммутатор Cisco Catalyst 6500
• Беспроводные точки доступа Cisco разных моделей (~1500 клиентов ежедневно) под управлением контроллера Cisco 44xx
• В интернет выпускает маршрутизатор Cisco 38xx
• В сети создано более 50 vlan-ов

Все это приправлено неопределенным количеством аппаратных и виртуальных серверов (точно более полусотни). Именно ввиду того что отсутствует всякая документация (записки админов не в счет) невозможно облечь параметры сети в какие-либо конкретные цифры.

Как так получилось?

Пару лет назад, когда стоял вопрос отделки новой квартиры, возникла тривиальная, казалось бы, задача.
Дано:

• Кухня-студия (кухня совмещенная с холлом/коридором), три точки освещения.
• Необходимо управлять освещением из двух точек. У входа в квартиру и на кухне.

Варианты решения:

• Покупаем, так называемые, проходные выключатели, ставим три штуки на кухню, три в коридоре — вот оно счастье. Вот только получилось, что от коридора на кухню нужно вести 9 жил кабеля, некрасиво, спрятать некуда.
• Покупаем готовые решения по управлению одним источником с нескольких точек.
  Точных чисел не помню, но получалось что-то около 10000р за точку освещения + 1000р за каждый выключатель, итого 36000р. Жаба.
• Как это ни странно, но эту идею высказала жена, в общем-то далекая от IT: “ А помнишь, ты светофор в Яндексе делал? Может тут тоже что-то сам сообразишь?”
  В самом деле, а почему бы и нет, подумал я?

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