Блог компании Jelastic → GlassFish кластеризация в Jelastic
Как вам уже известно, GlassFish — высоконадежный Java EE сервер приложений с полной поддержкой промышленной кластеризации и широким спектром функций.
До недавнего времени Glassfish использовался в Jelastic Java PaaS просто как отдельный сервер, теперь же мы поддерживаем все функции этого сервера, включая высокую доступность (HA).
Мы сберегли «родную» кластерную архитектуру GlassFish, которая основана на концепции административного домена. Административные домены состоят из кластеров и инстансов, контроль над которыми осуществляется с помощью DAS (Domain Administration Server).
Вы можете управлять центральным репозитарием с помощью админ консоли. Это легкий в использовании GUI, который поддерживает все фичи, доступные в Glassfish. DAS управляет Java инстансами домена, а GMS (Group Management Service) отвечает за предоставление информации о кластере и его инстансах.
До недавнего времени Glassfish использовался в Jelastic Java PaaS просто как отдельный сервер, теперь же мы поддерживаем все функции этого сервера, включая высокую доступность (HA).
Мы сберегли «родную» кластерную архитектуру GlassFish, которая основана на концепции административного домена. Административные домены состоят из кластеров и инстансов, контроль над которыми осуществляется с помощью DAS (Domain Administration Server).
Вы можете управлять центральным репозитарием с помощью админ консоли. Это легкий в использовании GUI, который поддерживает все фичи, доступные в Glassfish. DAS управляет Java инстансами домена, а GMS (Group Management Service) отвечает за предоставление информации о кластере и его инстансах.
Системное администрирование → Развертывание биллинга для небольшой сети с нуля
Предыстория:
Некие хорошие люди решили начинать провайдерский бизнес. Растянули и разварили оптику в небольшом районе, поставили ящички, засунули туда минимальные свичи, с помощью которых можно организовать VLAN-Per-User, закупили небольшой, для начала, канал у ближайшего магистрала. Встал у них вопрос о том, чем же считать пользователям трафик/денежки и нарезать скоростя.
Общая схема сети должна выглядеть следующим образом:
Кому интересно, далее под катом очень много букв и картинок.
Некие хорошие люди решили начинать провайдерский бизнес. Растянули и разварили оптику в небольшом районе, поставили ящички, засунули туда минимальные свичи, с помощью которых можно организовать VLAN-Per-User, закупили небольшой, для начала, канал у ближайшего магистрала. Встал у них вопрос о том, чем же считать пользователям трафик/денежки и нарезать скоростя.
Общая схема сети должна выглядеть следующим образом:
Кому интересно, далее под катом очень много букв и картинок.
Высокая производительность → In-memory-data-grid. Режимы работы, индексы, блокировки
Я продолжаю небольшой цикл статей на тему In-memory-data-grid.
В первой статье была раскрыта сама концепция IMDG без конкретных примеров и деталей реализации. Сегодня мы копнем чуть глубже.
В первой статье была раскрыта сама концепция IMDG без конкретных примеров и деталей реализации. Сегодня мы копнем чуть глубже.
Высокая производительность → In-memory-data-grid. Масштабируемые хранилища данных из песочницы
В последнее время интерес к облачным архитектурам растет с каждым днем, так как это один из наиболее эффективных способов масштабировать приложение, не прикладывая больших усилий, а самым узким местом любого высоконагруженного проекта является хранилище данных, в частности реляционная БД. Для борьбы с недостатками традиционных БД в основном используется 2 подхода:
1) Кэширование результатов выполнения запросов
2) NoSQL решения
Сегодня я хочу познакомить вас с таким типом хранилища данных, который объединяет достоинства обоих подходов и при этом имеет ряд преимуществ перед упомянутыми выше решениями: In-memory-data-grid (IMDG).
1) Кэширование результатов выполнения запросов
- плюсы: высокая скорость доступа к данным
- минусы: требует компромисса между актуальностью данных и скоростью доступа, т.к. данные в кэше могут устареть, а удалять старые данные из кэша с последующим кэшированием новых — это дополнительные задержки и нагрузка на систему
2) NoSQL решения
- плюсы: хорошая горизонтальная масштабируемость, доменная модель данных совпадает с моделью хранения данных
- минусы: низкая скорость получения результатов в случае использования диска, практически невозможно обеспечить работу внутрикорпоративного софта, который ориентирован на работу с конкретной реляционной БД.
Сегодня я хочу познакомить вас с таким типом хранилища данных, который объединяет достоинства обоих подходов и при этом имеет ряд преимуществ перед упомянутыми выше решениями: In-memory-data-grid (IMDG).
Серверная оптимизация → Gearman – фреймворк для распределения задач, введение из песочницы
В этой статье, мне бы хотелось рассмотреть один из необычных способов оптимизации приложения, а именно использование проекта Gearman для распределения задач. Gearman является фреймворком для построения таких систем. Примеров кода в статье нет, статья больше вводная, хоть и содержит в себе достаточно практической информации.
Облачные вычисления → Гигагерцы задешево — Win 2008R2 Core на Amazon из песочницы
Занимаясь стартапами я, наконец-то, дошел до той точки, когда нужно быть готовым отмасштабировать приложение на N серверов для 1M просмотров в день и я начал думать, как же это сделать наиболее эффективно с использованием Amazon Ec2.
Примерный план известен всем — сервер помощнее для базы данных и набор небольших серверов, которые запускаются/останавливаются по мере необходимости в зависимости от нагрузки.
Из недорогих серверов у амазона особого выбора нет. Изначально я планировал использовать для этого Small Instance — именно этот вариант рекомендует amazon по умолчанию. В нем 1.7 GB RAM, что довольно комфортно для windows, но только 1 ECU. На практике в памяти можно разместить 5-8 рабочих процессов, однако, толком работать одновременно они не способны — ядро одно и очень слабое: 1 ECU это всего-то 1 Ghz одного ядра Xeon образца 2007 года. По моим оценкам, примерный эквивалент — процессор Celeron на частоте 1.5 Ghz. Стоит такой сервер $0.12 в час ~ $86 в месяц, десяток — $860 в месяц… Было очевидно, что эта конфигурация сервера не совсем отвечает моим задачам.
Поэтому я решил попробовать Micro instance — всего-навсего 613 MB памяти, но зато:
Примерный план известен всем — сервер помощнее для базы данных и набор небольших серверов, которые запускаются/останавливаются по мере необходимости в зависимости от нагрузки.
Из недорогих серверов у амазона особого выбора нет. Изначально я планировал использовать для этого Small Instance — именно этот вариант рекомендует amazon по умолчанию. В нем 1.7 GB RAM, что довольно комфортно для windows, но только 1 ECU. На практике в памяти можно разместить 5-8 рабочих процессов, однако, толком работать одновременно они не способны — ядро одно и очень слабое: 1 ECU это всего-то 1 Ghz одного ядра Xeon образца 2007 года. По моим оценкам, примерный эквивалент — процессор Celeron на частоте 1.5 Ghz. Стоит такой сервер $0.12 в час ~ $86 в месяц, десяток — $860 в месяц… Было очевидно, что эта конфигурация сервера не совсем отвечает моим задачам.
Поэтому я решил попробовать Micro instance — всего-навсего 613 MB памяти, но зато:
- производительность достигает 2 ECU
- он в 4 раза дешевле
- можно использовать 64 битную платформу Windows Server 2008 R2 Core
Блог компании Оверсан → Независимая ширина сетевого канала в облаке Скалакси
Отличные новости! Компания Оверсан не стоит на месте, и сегодня мы анонсируем очередной релиз, маркированный, как 0.41, облака Скалакси.
На этот раз реализована сложная функция, которая потенциально сослужит добрую службу всем нашим клиентам. А именно — независимое масштабирование.
Можно сколько угодно ходить вокруг да около, но главный смысл передается одним предложением — отныне каждая виртуальная машина обладает ресурсом для масштабирования ширины внешнего сетевого канала, вне зависимости от оперативной памяти, в диапазоне от 5 Мбит/с до 300 Мбит/с, с шагом в 5 Мбит/с.
Соответственно, изменилась и тарификация используемых ресурсов. Раньше цельный слот, состоящий из 512 Mбайт RAM и 5 Мбит/с пропускной способности, стоил 65 копеек в час. Сейчас мы тарифицируем отдельно мегабайты оперативной памяти (по 40 копеек за 512 Мбайт в час) и пропускную способность сети (по 5 копеек за 1 Мбит/с в час).
На этот раз реализована сложная функция, которая потенциально сослужит добрую службу всем нашим клиентам. А именно — независимое масштабирование.
Можно сколько угодно ходить вокруг да около, но главный смысл передается одним предложением — отныне каждая виртуальная машина обладает ресурсом для масштабирования ширины внешнего сетевого канала, вне зависимости от оперативной памяти, в диапазоне от 5 Мбит/с до 300 Мбит/с, с шагом в 5 Мбит/с.
Соответственно, изменилась и тарификация используемых ресурсов. Раньше цельный слот, состоящий из 512 Mбайт RAM и 5 Мбит/с пропускной способности, стоил 65 копеек в час. Сейчас мы тарифицируем отдельно мегабайты оперативной памяти (по 40 копеек за 512 Мбайт в час) и пропускную способность сети (по 5 копеек за 1 Мбит/с в час).
Kohana → Масштабирование веб-приложений с помощью HMVC
Последние десять лет мы наблюдаем второй цикл веб-дизайна – сайты превращаются в приложения и уже практически не появляется новых проектов, не обладающих некой долей интерактивности. Увеличение сложности ПО, разрабатываемого для интернета, вызвало необходимость в структурированном и взвешенном проектировании приложений.
На сегодняшний день наиболее часто используемым паттерном проектирования сайтов является Модель-Вид-Контроллер (MVC). Повсеместное его использование отчасти вызвано успехом и популярностью фреймворка Ruby on Rails. Сейчас MVC является практически синонимом веб-разработки среди всех платформ.
При выполнении задач, активно нагружающих процессор, современные сайты все больше полагаются на выделенные ресурсы. Этому, в частности, поспособствовало открытие компаниями Amazon и Google облачных сервисов, которые позволяют разработчикам существенно уменьшить нагрузку на процессоры их собственных серверов. Каждый сервис обычно проектируется в виде отдельного элемента ПО, который запускается внутри своего домена и использует свои собственные ресурсы.
Когда имеешь дело со скромными бюджетами, обычно довольно сложно убедить клиентов в преимуществах финансирования более чем одного завершенного фрагмента программного обеспечения. Как показывает мой опыт, множество из них придерживаются мнения, что масштабируемость не является актуальной задачей. Они «с нетерпением ждут того дня, когда придется этим обеспокоиться».
Для уменьшения первоначальных вложений обычно принимают решение о том, что приложение должно быть спроектировано в виде целостной программы, содержащей все требуемые функции. Если сайт быстро обретет популярность, это станет проблемой. У меня остались не очень приятные впечатления от рефакторинга плохо масштабируемых кодовых баз. К тому же, это может потребовать большого количества ресурсов и денег. В идеале приложения должны расти по мере необходимости и не требовать в процессе этого крупных финансовых затрат.
На сегодняшний день наиболее часто используемым паттерном проектирования сайтов является Модель-Вид-Контроллер (MVC). Повсеместное его использование отчасти вызвано успехом и популярностью фреймворка Ruby on Rails. Сейчас MVC является практически синонимом веб-разработки среди всех платформ.
При выполнении задач, активно нагружающих процессор, современные сайты все больше полагаются на выделенные ресурсы. Этому, в частности, поспособствовало открытие компаниями Amazon и Google облачных сервисов, которые позволяют разработчикам существенно уменьшить нагрузку на процессоры их собственных серверов. Каждый сервис обычно проектируется в виде отдельного элемента ПО, который запускается внутри своего домена и использует свои собственные ресурсы.
Когда имеешь дело со скромными бюджетами, обычно довольно сложно убедить клиентов в преимуществах финансирования более чем одного завершенного фрагмента программного обеспечения. Как показывает мой опыт, множество из них придерживаются мнения, что масштабируемость не является актуальной задачей. Они «с нетерпением ждут того дня, когда придется этим обеспокоиться».
Для уменьшения первоначальных вложений обычно принимают решение о том, что приложение должно быть спроектировано в виде целостной программы, содержащей все требуемые функции. Если сайт быстро обретет популярность, это станет проблемой. У меня остались не очень приятные впечатления от рефакторинга плохо масштабируемых кодовых баз. К тому же, это может потребовать большого количества ресурсов и денег. В идеале приложения должны расти по мере необходимости и не требовать в процессе этого крупных финансовых затрат.
PostgreSQL → Работа с Postgresql: настройка, масштабирование. Дополненное издание
Привет всему хабросообществу.
Время не стоит на месте. После публикации моего справочника по Postgresql очень многое успело поменяться, а точнее добавиться в эту отличную СУБД. После выхода PostgreSQL 9 версии я понял, что потребуется добавить информацию о нововведениях для этой версии. Тем более, что 9 версия знаменуется выходом репликации из коробки.
Блог компании Clodo → Масштабируемый сервер в облаке — Scale Server
Несомненно, «облачные» вычисления в данный момент являются трендом рынка хостинговых услуг. Почти каждый хостинг-провайдер предоставляющий услуги аренды виртуальных серверов заявляет, что работает в «облаке». Зачастую эти заявления всего лишь красивая маркетинговая обложка скрывающая за собой традиционный подход к предоставлению услуг аренды VDS/VPS.
Следуя тенденциям рынка, мы отбросили в сторону маркетинговые фантики и рады анонсировать на Хабре нашу новую услугу — Scale Server.
Следуя тенденциям рынка, мы отбросили в сторону маркетинговые фантики и рады анонсировать на Хабре нашу новую услугу — Scale Server.