Если Вы программируете на node.js, но устали писать роутинг запросов в коде, у Вас нет предубеждения против использования глобальных переменных в служебных целях и Вы согласны, что излишняя свобода губительна для масс, то тоталитарный кружок выходного дня приготовил для Вас прототип альтернативной платформы для разработки веб приложений. Предупреждаю, что тоталитарный стиль предполагает не встраивание фреймворка в приложение через require, а наоборот, встраивание своего приложения в структуру фреймворка, где фрагменты кода приложения будут на каждом шагу иметь дело с дополнительными ограничениями и навязанными структурами кода и данных. Про то, что «less-than-expert» смогут разрабатывать высокопроизводительные системы, как утверждают разработчики ноды — ну тут Вы сами понимаете, что это будут за системы, особливо асинхронные, с потерянными коллбеками и утечками памяти на каждом шагу. В плане защиты от дурака, сей прототип чудес не доставляет. И конечно же, ожидаю от Вас много конструктивной критики, потому, что прототип сырой, хоть и собрал в себе множество концептуальных наработок нашей команды за последнее десятилетие. Даже название Impress появилось всего два дня назад и, да — это самый сложный вопрос.
Читать полностью »
Рубрика «cluster» - 4
Прототип тоталитарного фреймворка для node.js
2013-06-10 в 11:28, admin, рубрики: cluster, framework, Impress, javascript, node.js, statefull, Веб-разработка, метки: cluster, framework, Impress, node.js, statefull, web-applicationКластерное хранилище в Proxmox. Часть третья. Нюансы
2013-04-30 в 7:50, admin, рубрики: cluster, gfs2, iscsi, openvz, proxmox, Блог компании «Alawar Entertainment», виртуализация, системное администрирование, метки: cluster, gfs2, iscsi, openvz, proxmox Здравствуйте!
Третья часть статьи является своеобразным приложением к двум предыдущим, в которых я рассказывал о работе с Proxmox-кластером. В этой части я опишу проблемы, с которыми мы сталкивались в работе с Proxmox, и их решения.
Авторизованное подключение к iSCSI
Если вам понадобилось при подключении к iSCSI указать креденшиалы — лучше это делать в обход Proxmox. Почему?
- Во-первых, потому что через web-интерфейс Proxmox невозможно создать авторизованное iSCSI-подключение.
- Во-вторых, даже если вы решите создать в Proxmox неавторизованное подключение с тем, чтобы указать авторизационную информацию вручную, то вам придется бодаться с системой за возможность изменить конфигурационные файлы таргетов, так как при неудачной попытке подключения к iSCSI-хосту Proxmox перезаписывает информацию о таргетах и производит повторную попытку подключения.
Кластер высокой доступности на Red Hat Cluster Suite
2013-04-05 в 13:12, admin, рубрики: cluster, high availability, linux, red hat, Песочница, метки: cluster, high availability, red hatВ поисках решения для построения HA кластера на linux, я наткнулся на довольно интересный продукт, который, по моим наблюдениям, несправедливо обделен вниманием уважаемого сообщества. Судя по русскоязычным статьям, при необходимости организации отказоустойчивости на уровне сервисов, более популярно использование heartbeat и pacemaker. Ни первое, ни второе решение у нас в компании не прижилось, уж не знаю почему. Может сыграла роль сложность конфигурации и использования, низкая стабильность, отсутствие подробной и обновляемой документации, поддержки.
После очередного обновления centos, мы обнаружили, что разработчик pacemaker перестал поддерживать репозиторий для данной ОС, а в официальных репозиториях была сборка, подразумевающая совершенно другую конфигурацию (cman вместо corosync). Переконфигурировать pacemaker желания уже не было, и мы стали искать другое решение. На каком-то из англоязычных форумов, я прочел про Red Hat Cluster Suite, мы решили его попробовать.
Общая информация
RHCS состоит из нескольких основных компонентов:
- cman — отвечает за кластеризацию, взаимодействие между нодами, кворум. По сути, он и собирает кластер.
- rgmanager — менеджер ресурсов кластера, занимается добавлением, мониторингом, управлением групп ресурсов кластера.
- ricci — демон для удаленного управления кластером
- luci — красивый веб интерфейс, который подключается к ricci на всех нодах и предоставляет централизованное управление через веб-интерфейс.
Как и в heartbeat и pacemaker, ресурсы кластера управляются стандартизированными скриптами (resource agents, RA). Кардинальное отличие от pacemaker состоит в том, что redhat не подразумевает добавления пользовательских кастомных RA в систему. Но это с лихвой компенсируется тем, что есть универсальный resource agent для добавления обычных init скриптов, он называется script.
Управление ресурсами идет только на уровне групп сервисов. Сам по себе ресурс невозможно включить или выключить. Для распределения ресурсов по нодам и приоритезации запуска на определенных нодах используются failover domains, домен представляет собой правила запуска групп ресурсов на определенных нодах, приоритезацию и failback. Одну группу ресурсов можно привязать к одному домену.
Кластерное хранилище в Proxmox. Часть вторая. Запуск
2013-01-24 в 13:52, admin, рубрики: cluster, gfs2, iscsi, proxmox, Блог компании «Alawar Entertainment», виртуализация, системное администрирование, метки: cluster, gfs2, iscsi, proxmox 
Здравствуйте!
Это вторая часть статьи о работе c кластерным хранилищем в Proxmox (первую можно найти тут). Сегодня поговорим о подключении хранилища к кластеру.
В качестве кластерной системы мы используем Global File System 2.
GFS2 в Proxmox функциональна, но разработчики Proxmox официально не поддерживают ее. Однако ядро Proxmox основано на RedHat-ядре RHEL6x-ветки. То есть поддержка GFS2 в ядре весьма зрелая. Обвязка тоже ведет себя вполне стабильно, за исключением нескольких нюансов, о которых я расскажу позже. Сам пакет gfs2-utils представляет собой практически не измененную (есть лишь патчи в стартовых скриптах на предмет подгона под дебиановскую специфику) стабильную редхатовскую версию gfs2-utils-3.1.3
Пакет gfs2-utils появился в Proxmox в феврале 2012 года. Родной же дебиановский пакет gfs2-tools дико конфликтует (что неудивительно) со всем RedHat-кластером из Proxmox, поэтому до Proxmox версии 2.0 из коробки GFS2 была совершенно неюзабельна.
Итак, огромным плюсом является то, что фундамент для взведения GFS2 в Proxmox уже выстроен.
Читать полностью »
Кластерное хранилище в Proxmox. Часть первая. Fencing
2012-12-20 в 10:27, admin, рубрики: cluster, proxmox, Блог компании «Alawar Entertainment», виртуализация, системное администрирование, метки: cluster, proxmox Здравствуйте!
Хочу рассказать о том, как мы используем у себя Proxmox Virtual Environment.
Я не буду описывать установку и первоначальную настройку — Proxmox очень прост и приятен и в установке, и в настройке. Расскажу о том, как мы используем систему в кластерном окружении.
Для полноценной работы кластера необходимо, чтобы управление виртуальной машиной оперативно могли брать на себя разные хосты кластера. Данные виртуалок при этом не должны никуда копироваться. То есть все хосты кластера должны иметь доступ к данным конкретной машины, или, иными словами, все хосты кластера должны работать с единым хранилищем данных, в рамках которого работает конкретный набор виртуальных машин.
Proxmox работает с двумя типами виртуализации: уровня операционной системы, на основе OpenVZ и аппаратной, на основе KVM. В этих двух типах используется разный подход к утилизации дискового пространства. Если в случае с OpenVZ-контейнерами работа с диском виртуальной машины осуществляется на уровне файловой системы хоста, то в случае с KVM-машинами используется образ диска, в котором находится собственная файловая система виртуальной машины. Операционная система хоста не заботится о размещении данных внутри KVM-диска. Этим занимается гипервизор. При организации работы кластера вариант с образами диска реализуется проще, чем работа с файловой системой. Данные KVM-машины с точки зрения операционной системы хоста могут просто находиться "где-то" в хранилище. Эта концепция замечательно ложится на схему работы LVM, когда образ KVM-диска находится внутри логического тома.
В случае же с OpenVZ мы имеем дело с файловой системой, а не просто с областями данных на Shared Storage. Нам нужна полноценная кластерная файловая система.
О кластерной файловой системе речь пойдет не в этой части статьи. О работе с KVM — тоже. Сейчас поговорим о подготовке кластера к работе с общим хранилищем.
Читать полностью »
AWS Insight: Как работают Placement Groups
2012-12-04 в 10:48, admin, рубрики: Amazon Web Services, AWS, cluster, Блог компании EPAM Systems Ukraine, Облачные вычисления, метки: aws, cluster Привет! 
У многих есть проекты с «хайлоадом». Немногие используют кластеры на AWS. И те, кто всё-таки их используют, должны использовать Placement группы.
Что это такое
Placement Groups (Группы размещения) — логические объединения кластерных типов AWS инстансов, позволяющие уменьшить сетевые задержки. AWS гарантирует скорость в 10 Gb между серверами, запущенными в одной плейсмент группе. Чисто теоретически, эти инстансы запускаются географически рядом.
При обычном размещении инстансов получается приблизительно следующая картина:
Читать полностью »
Реализация резервирования сервера Asterisk
2012-11-28 в 8:37, admin, рубрики: asterisk, cluster, digium, ip-телефония, резервирование, Телекомы, метки: asterisk, cluster, digium, резервирование Одним из главных критериев при выборе новой АТС это надежность, отказоустойчивость и возможность резервирования системы. Маленьким и средним компаниям обычно хватает простого бэкапа с возможностью восстановиться в течение 24 часов, в то время как для больших компании это очень критично и не может быть и речи о простое телефонной связи. На это обычно компания тратят много ресурсов и денег. С появлением R800 и R850 от компании DIGIUM, asterisk становится действительно надежной системой с полноценным резервированием. Под катом подробности установки и настройки двух серверов Asterisk и R850.
Читать полностью »
Живая миграция виртуальных машин в ProxMox VE 2.x
2012-07-22 в 3:26, admin, рубрики: cluster, high availability, kvm, proxmox, qemu, виртуализация, живая миграция, системное администрирование, метки: cluster, high availability, kvm, proxmox, qemu, виртуализация, живая миграция 
Недавно был поднят вопрос об использовании VmWare vMotion в небольшом кластере гипервизоров, однако цена данной возможности заставила немного пошевелиться в поисках альтернатив.
Так родился небольшой тестовый дайджест по настройке и эксплуатации возможности Live Migration виртуальных машин на основе QEMU в ProxMox VE 2.1 с использованием iSCSI NAS.
Нужно сказать что во второй версии ProxMox VE, девелоперы избавились от центральной ноды менеджмента кластера. Теперь ее роль может исполнять любая нода кластера, «был бы кворум» (с)
NetApp Data ONTAP 8 — Storage Hypervisor
2012-03-29 в 4:50, admin, рубрики: cloud storage, cluster, hypervisor, NAS, NetApp, SAN, storage, Блог компании NetApp, виртуализация, Облачные вычисления, метки: cloud storage, cluster, hypervisor, NAS, NetApp, SAN, storage 
Этот год для компании станет «годом Cluster-mode», несмотря на то, что поддерживающая этот режим работы версия Data ONTAP, собственная внутренняя OS, которая работает во всех системах хранения NetApp, в версии 8.0 вышла еще в 2008 году, по настоящему ее возможности по созданию «многоузлового кластера хранения» начинают реализовываться только сейчас.
Но для начала немного истории.
О перспективах развития систем хранения в направлении «облачных» систем начали говорить уже несколько лет назад, хотя тогда еще не вошло в IT-лексикон это модное слово, и тогда говорили о GRID-системах, идущих на смену «классическим» сетевым системам хранения.
Нет ничего удивительного в том, что NetApp, как компания традиционно много внимания уделяющая перспективным направлениям в отрасли, занялась темой «облачных» кластерных систем одной из первых. И вот что из этого получилось.
Читать полностью »