Масштабируемый WordPress-кластер почти бесплатно


Оглавление (нажмите, чтобы открыть):

Вертикальное и горизонтальное масштабирование, scaling для web

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

Возможности для масштабирования для серверов баз данных определяются применяемыми программными решениями: чаще всего это реляционные базы данных (MySQL, Postgresql) или NoSQL (MongoDB, Cassandra и др).

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

Веб-проект обычно начинают на одном сервере, ресурсы которого при росте заканчиваются. В такой ситуации возможны 2 варианта:

  • перенести сайт на более мощный сервер
  • добавить еще один сервер небольшой мощности с объединить машины в кластер

MySQL является самой популярной RDBMS и, как и любая из них, требует для работы под нагрузкой много серверных ресурсов. Масштабирование возможно, в основном, вверх. Есть шардинг (для его настройки требуется вносить изменения в код) и репликация, которая может быть сложной в поддержке.

Вертикальное масштабирование

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

Таким образом с MySQL нужен будет сервер с большим количеством CPU и оперативной памяти, такие сервера имеют значительную стоимость.

Горизонтальное масштабирование
С MongoDB можно добавить еще один средний сервер и полученное решение будет стабильно работать давая дополнительно отказоустойчивость.

Scale-out или горизонтальное масштабирование является закономерным этапом развития инфраструктуры. Любой сервер имеет ограничения и когда они достигнуты или когда стоимость более мощного сервера оказывается неоправданно высокой добавляются новые машины. Нагрузка распределяется между ними. Также это дает отказоустойчивость.

Добавлять средние сервера и настраивать кластеры нужно начинать когда возможности для увеличения ресурсов одной машины исчерпаны или когда приобретение сервера мощнее оказывается невыгодно

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

Подбор хостинга с возможностью масштабирования. Какой?

Рекомендую ознакомиться с проектом FirstVDS:
Есть два масштабируемых тарифа:

Оба тарифа масштабируемые, с возможностью выбора ISPmanager, опционально подключается защищенный канал от DDoS (при атаке на сетевом/транспортном уровне).
Есть отдельная защита от DDoS-атак на уровне данных (домена).
Свой Дата-центр в России. Аптайм 99,6%. Поддержка 24/7

На VPS/VDS ты САМ ставишь любое ПО
Поэтому требование с Python — это смысла лишено. Че хочешь то и поставишь.
Может быть ты имел ввиду vip-shared, а не VPS?

Настоящее облако далеко не всегда имеет смысл:
1. Дороже VPS
2. Желательно чтобы софт был адоптирован под облако, иначе еще больше переплатишь.
3. Обычный VPS масштабируется в пределах тарифов.

То есть берешь самый дешевый тариф VPS
И постепенно меняешь его — доводишь до самого дорого.

Ну прям до самого дорогого — это смысла лишено. Лучше остановиться посередине, а потом пересесть на dedicated
Ибо самые дорогие VPS — могут стоить дороже dedicated.
Ты только на админе экономишь (что в VPS уже настроенная ОС), а с дедиком нужно повозиться.

Ну например, ruweb.net
Все есть. Работает стабильно. Анди-ДДоС есть. Цены адекватные — в OVH даже дороже.
Физически расположены в Подмосковье.
Для российских клиентов скорость будет заметно быстрее, чем с OVH

Нормально масштабирование — это прежде всего особенность АРХИТЕКТУРЫ вашей системы.
А не хостинга.

Бывает 2 вида масштабирования:

Горизонтальное и вертикальное.

Вертикальное — дается хостингом в небольших пределах. По мере роста вертикального масштабирования — цена дико растет.

Горизонтальное — реализуется прежде всего внутри вашей системы. Хостер тут не причем. Кое-какое вспоможение хостер может давать (например, вы выкупаете 3 сервера у хостера и между ними нелимитированная связь по недоступному извне каналу — это то что доктор прописал для горизонтального масштабирования).

WordPress.org

Русский

Отказоустойчивый WP

Есть 2 одинаковых виндовых сервера 2020, поднят IIS.
На обоих развернут WP.
Можно ли сделать так, чтобы в реальном времени БД синхронизировались между собой?
Что-то типа https://artemkomarov.ru/blog/kak-sinhronizirovat-bd-vordpress-mezhdu-2-saytami/
Т.е. нужно в итоге либо через NLB или DnsRRobin чтобы пользователь попадал бы на любой сервер\сайт на нем и данные синхронизировались.

Может еще какой алгоритм есть? Кластер из 3х серверов с общим диском не подходит — накладно.

Вам на форум гуру-форточников.
А здесь форум по ВП.
И ваш вопрос сильно выпадает за его рамки и может считаться офтопом.

«мьсе знает толк….» (с)

будет лучше , дешевле и проще сделать это все на масштабируемой cloud vps

думаю, что не важно на чем развернут.
спрошу по другому — как синхронизировать 2 сайта в реальном времени (изначально одинаково настроенных)? пользователи заходят на сайты по имени rrobin dns, рандомно попадая на каждый.

будет лучше , дешевле и проще сделать это все на масштабируемой cloud vps

в подоконном мире такого щястья не существует, только хардкор

думаю, что не важно на чем развернут.

какие слова в фразе «этот форум не по системному администрированию» вам не понятны?

плагины входят в системное администрирование? +вопросы же теоретические и мелкие.

а вот такой вариант работать будет?
Настраиваем 1 сайт. А на 2м просто цепляем БД 1го.

Настраиваем 1 сайт. А на 2м просто цепляем БД 1го.

но вам еще придется решить вопрос с синхронизацией файлов

да и при отказе сервера БД сами понимаете что случится со вторым, если конечно не настроите репликацию

плагины входят в системное администрирование?

вы где-то видели плагины, которые вмешиваются в работу разных серверов?
причем на винде. в чем вы варите то, что курите?

если интересно. пока получилось поднять кластер MySQL 8 на ws2020.
больше года не занимался wp. сейчас какая версия стаб. последняя?
с какой макс. php и MySQL дружит?
теперь попробую поднять 2 сервера\сайта с 1й базой, если кто ответит по версиям.
2 Yui — спасибо за ответ. не думаю, что там будет много файлов измененных, сайт внутр. и предполагается только контент менять, без генерации страниц и тд.
но да, об этом не подумал. но файлы как раз меньше всего беспокоят, это множество способов е.для синхр (или даже просто один выд.ф.сервер).

  • Ответ изменён 7 мес. назад пользователем ☭Gu.

Не знаю, есть ли инструменты для винды, но для БД вам потребуется настроить Master-Slave или Master-Master репликацию MySQL. Первый вариант, если второй сайт будет как бэкап, второй вариант, если изменения в любом из сайтов должны отразиться на другом.
Также вам потребуется настроить репликацию файловой системы. Может Linux лучше поставите?

спасибо за ответ.
1. как раз кластерность проблему решает (я о БД)
2. да, согласен, ранее мне тоже модер об этом

но в 2020 iis доступно вроде как не физ. хран. а сетевое.
пока тестю WP на одной ноде.

wp на iis ставил кусками через их «web platform». Но только часть, посмотрел чего ставит, потом лишний хлам снес.
Короче пока 1 ноду удалось зацепить к БД. Ща там отд. вопросы, после отпишу.

как финал. да, получилось.
Wp сайт (файлы) перенесен в отказоустойчивый ФС (да, по «\\», и также публикуется).
БД тоже на аналоге лежит.
2 сервера поднято с iis, nlb тоже уст. (да отдельный ip, и адрес в домене) До последнего не думал что получится, но работает.
Вопрос закрыт.

Автоматическое развертывание масштабируемого сайта WordPress

Данный мануал поможет создать и развернуть масштабируемый экземпляр WordPress, состоящий из сервера базы данных MySQL, распределенной файловой системы GlusterFS, веб-серверов Nginx и балансировщика нагрузки Nginx. Используя пользовательские данные и метаданные сервера, вы можете автоматизировать развертывание сайта. Сценарий Ruby может облегчит создание масштабируемых сайтов WordPress.


1: Планирование развертывания

Развертывание в этом мануале будет состоять из одного сервера базы данных MySQL, нескольких серверов GlusterFS в кластере, нескольких веб-серверов Nginx и одного балансировщика нагрузки Nginx.

Прежде чем начать, вам нужно точно знать:

  • размер сервера MySQL
  • количество нод GlusterFS
  • размер нод GlusterFS
  • количество нод веб-серверов
  • размер нод веб-серверов
  • размер ноды балансировщика нагрузки
  • домен нового сайта

В дальнейшем вы можете добавить дополнительные ноды или увеличить количество ресурсов этих нод.

2: Развертывание MySQL

Начнем с развертывания сервера MySQL. Для этого нужно создать 64-бинтый сервер Ubuntu 14.04, используя следующие пользовательские данные.

#!/bin/bash
export DEBIAN_FRONTEND=noninteractive;
export PUBLIC_IP=$(curl -s https://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)
export PRIVATE_IP=$(curl -s https://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address)
apt-get update;
apt-get -y install mysql-server;
mysqladmin -u root create wordpress;
mysqladmin -u root password «mysql_password»;
sed -i.bak «s/127.0.0.1/$PRIVATE_IP/g» /etc/mysql/my.cnf;
service mysql restart;
mysql -uroot -pmysql_password -e «CREATE USER ‘wordpress’@’%’ IDENTIFIED BY ‘mysql_password'»;
mysql -uroot -pmysql_password -e «GRANT ALL PRIVILEGES ON wordpress.* TO ‘wordpress’@’%'»;

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

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

Затем с помощью метаданных сервера сценарий собирает внешний и внутренний IP-адрес и присваивает их переменным:

export PUBLIC_IP=$(curl -s https://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)
export PRIVATE_IP=$(curl -s https://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address)

Затем apt устанавливает MySQL.

apt-get update;
apt-get -y install mysql-server;

После этого нужно создать новую базу данных по имени wordpress.

mysqladmin -u root create wordpress;

и установить пароль для root-пользователя MySQL.

mysqladmin -u root password «mysql_password»;

Поскольку сервер MySQL будет принимать запросы с веб-серверов, нужно, чтобы он прослушивал внутренний IP-адрес, а не только localhost. Сценарий использует sed для обновления конфигурационного файла MySQL, выполнив поиск и замену, а затем перезапускает сервис.

sed -i.bak «s/127.0.0.1/$PRIVATE_IP/g» /etc/mysql/my.cnf;
service mysql restart;

Затем он создает нового пользователя MySQL по имени wordpress:

mysql -uroot -pmysql_password -e «CREATE USER ‘wordpress’@’%’ IDENTIFIED BY ‘mysql_password'»;
mysql -uroot -pmysql_password -e «GRANT ALL PRIVILEGES ON wordpress.* TO ‘wordpress’@’%'»;

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

3: Развертывание GlusterFS

Перед развертыванием кластера GlusterFS вам нужно решить, сколько нод в нем должно быть. Для этого есть две переменные. Во-первых, нужно указать размер нод, а затем нужно принять решение о настройке реплики. Этот параметр указывает GlusterFS, сколько копий файла нужно хранить. Например, если replica – 2, то каждый файл дублируется не менее чем на 2 серверах. Это сократит доступное пространство вдвое, поскольку GlusterFS будет сохранять две копии каждого файла, но это обеспечивает хорошую избыточность. Количество создаваемых нод GlusterFS должно быть кратным параметру replica. Для кластера со значением «replica 2» нужно будет создать количество нод, кратное 2 (2, 4, 6 или 8 нод и т.д.).

В данном примере кластер GlusterFS будет состоять из 4 нод.

Для первых трех нод используйте такой сценарий:

#!/bin/bash
export DEBIAN_FRONTEND=noninteractive;
apt-get update;
apt-get install -y python-software-properties;
add-apt-repository -y ppa:gluster/glusterfs-3.5;
apt-get update;
apt-get install -y glusterfs-server;

Опять же, сначала устанавливается переменная DEBIAN_FRONTEND, благодаря чему apt знает, что работать нужно в неинтерактивном режиме:

Затем сценарий обновляет индекс пакетов и устанавливает python-software-properties, с помощью которого добавляется PPA для GlusterFS.

apt-get update;
apt-get install -y python-software-properties;

Затем сценарий добавляет GlusterFS PPA, чтобы иметь возможность загрузить пакет:

add-apt-repository -y ppa:gluster/glusterfs-3.5;

После сценарий обновит индекс пакетов и установит glusterfs-server.

apt-get install -y glusterfs-server;

Так выглядит сценарий для первых трех нод кластера. Обратите внимание на внутренние IP-адреса, присвоенные каждому из этих новых серверов – они понадобятся вам при создании последней ноды GlusterFS и создании тома.

Для последней ноды нужно использовать следующий сценарий пользовательских данных:

#!/bin/bash
export DEBIAN_FRONTEND=noninteractive;
export PRIVATE_IP=$(curl -s https://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address)
apt-get update;
apt-get install -y python-software-properties;
add-apt-repository -y ppa:gluster/glusterfs-3.5;
apt-get update;
apt-get install -y glusterfs-server;
sleep 30;
gluster peer probe node1_private_ip;
gluster peer probe node2_private_ip;
gluster peer probe node3_private_ip;
gluster volume create file_store replica 2 transport tcp node1_private_ip:/gluster node2_private_ip:/gluster node3_private_ip:/gluster $PRIVATE_IP:/gluster force;
gluster volume start file_store;

Примечание: Если вы не хотите включать репликацию, удалите параметр «replica» в команде «volume create».

Первый раздел этого сценария очень похож на тот, который использовался для создания предыдущих нод GlusterFS. IP-адрес нового сервера присваивается переменной $PRIVATE_IP. После установки glusterfs-server выполняет дополнительную работу.

Во-первых, сценарий будет ждать 30 секунд для запуска нового glusterfs-server.

Затем он проверяет три ноды GlusterFS, чтобы добавить все четыре в кластер.

gluster peer probe node1_private_ip;
gluster peer probe node2_private_ip;
gluster peer probe node3_private_ip;

Затем он создает том GlusterFS по имени filestore с параметром replica 2 и включает все четыре ноды. Поскольку вы не знаете IP-адрес последней ноды, используйте для нее переменную $PRIVATE_IP.

gluster volume create file_store replica 2 transport tcp node1_private_ip:/gluster node2_private_ip:/gluster node3_private_ip:/gluster $PRIVATE_IP:/gluster force;

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

gluster volume start file_store;

Теперь у вас есть распределенная файловая система, где можно хранить файлы WordPress, которые будут доступны для всех нод веб-сервера.

4: Развертывание нод Nginx

Теперь сервер базы данных и распределенная файловая система готовы, и вы можете развернуть веб-серверы. Используйте следующий сценарий пользовательских данных для развертывания первой ноды веб-сервера Nginx и настройки установки WordPress внутри тома GlusterFS.

#!/bin/bash
export DEBIAN_FRONTEND=noninteractive;
export PRIVATE_IP=$(curl -s https://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address)
apt-get update;
apt-get -y install nginx glusterfs-client php5-fpm php5-mysql;
sed -i s/\;cgi\.fix_pathinfo\=1/cgi\.fix_pathinfo\=0/g /etc/php5/fpm/php.ini;
mkdir /gluster;
mount -t glusterfs gluter_node_private_ip:/file_store /gluster;
echo «gluster_node_private_ip:/file_store /gluster glusterfs defaults,_netdev 0 0» >> /etc/fstab;
mkdir /gluster/www;
wget https://raw.githubusercontent.com/ryanpq/do-wpc/master/default -O /etc/nginx/sites-enabled/default;
service nginx restart;
# Get WordPress Files
wget https://wordpress.org/latest.tar.gz -O /root/wp.tar.gz;
tar -zxf /root/wp.tar.gz -C /root/;
cp -Rf /root/wordpress/* /gluster/www/.;
cp /gluster/www/wp-config-sample.php /gluster/www/wp-config.php;
sed -i «s/’DB_NAME’, ‘database_name_here’/’DB_NAME’, ‘wordpress’/g» /gluster/www/wp-config.php;
sed -i «s/’DB_USER’, ‘username_here’/’DB_USER’, ‘wordpress’/g» /gluster/www/wp-config.php;
sed -i «s/’DB_PASSWORD’, ‘password_here’/’DB_PASSWORD’, ‘mysql_password’/g» /gluster/www/wp-config.php;
sed -i «s/’DB_HOST’, ‘localhost’/’DB_HOST’, ‘mysql_private_ip’/g» /gluster/www/wp-config.php;
chown -Rf www-data:www-data /gluster/www;

Этот сценарий немного сложнее, чем предыдущие.

Сначала он устанавливает переменную DEBIAN_FRONTEND и $PRIVATE_IP.

export DEBIAN_FRONTEND=noninteractive;
export PRIVATE_IP=$(curl -s https://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address)

После этого он обновляет индекс пакетов и устанавливает Nginx, клиент glusterfs и библиотеки php.

apt-get update;
apt-get -y install nginx glusterfs-client php5-fpm php5-mysql;

Затем сценарий с помощью sed обновляет файл php.ini и устанавливает в переменной cgi.fixpathinfo значение 0.


sed -i s/\;cgi\.fix_pathinfo\=1/cgi\.fix_pathinfo\=0/g /etc/php5/fpm/php.ini;

После этого сценарий создает папку /gluster в корне образа диска и монтирует там том GlusterFS. Далее он создает запись fstab, чтобы том GlusterFS автоматически монтировался при загрузке сервера.

mkdir /gluster;
mount -t glusterfs gluter_node_private_ip:/file_store /gluster;
echo «gluster_node_private_ip:/file_store /gluster glusterfs defaults,_netdev 0 0» >> /etc/fstab;

Затем сценарий создаст папку под названием www в томе GlusterFS. Эта папка будет действовать как корневой каталог веб-сервера.

Далее он загружает новый конфигурационный файл Nginx с удаленного сервера. Этот файл установит корневой каталог веб-сервера в /gluster/www и настроит Nginx для поддержки PHP. Вы можете просмотреть этот конфигурационный файл здесь. После замены конфигурационного файла Nginx нужно перезапустить сервис.

wget https://raw.githubusercontent.com/ryanpq/do-wpc/master/default -O /etc/nginx/sites-enabled/default;

После этого сценарий скопирует последнюю версию WordPress, распакует и переместит ее в новый корневой каталог:

wget https://wordpress.org/latest.tar.gz -O /root/wp.tar.gz;
tar -zxf /root/wp.tar.gz -C /root/;
cp -Rf /root/wordpress/* /gluster/www/.;

Затем нужно скопировать образец конфигурации WordPress в файл wp-config.php.

cp /gluster/www/wp-config-sample.php /gluster/www/wp-config.php;

Сценарий обновит переменные в соответствии с новой средой, снова используя функцию поиска и замены sed.

sed -i «s/’DB_NAME’, ‘database_name_here’/’DB_NAME’, ‘wordpress’/g» /gluster/www/wp-config.php;
sed -i «s/’DB_USER’, ‘username_here’/’DB_USER’, ‘wordpress’/g» /gluster/www/wp-config.php;
sed -i «s/’DB_PASSWORD’, ‘password_here’/’DB_PASSWORD’, ‘mysql_password’/g» /gluster/www/wp-config.php;
sed -i «s/’DB_HOST’, ‘localhost’/’DB_HOST’, ‘mysql_private_ip’/g» /gluster/www/wp-config.php;

В конце он убедится, что файлы в корневом каталоге веб-сервера принадлежат пользователю www- data, который будет выполнять процесс Nginx.

chown -Rf www-data:www-data /gluster/www;

Теперь у вас есть первая нода веб-сервера, готовая к отправке запросов.

Поскольку каждая из нод веб-сервера использует один и тот же том GlusterFS для хранения файлов, для создания остальных нод потребуется меньше действий. Используйте следующий сценарий пользовательских данных:

#!/bin/bash
export DEBIAN_FRONTEND=noninteractive;
export PRIVATE_IP=$(curl -s https://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address)
apt-get update;
apt-get -y install nginx glusterfs-client php5-fpm php5-mysql;
sed -i s/\;cgi\.fix_pathinfo\=1/cgi\.fix_pathinfo\=0/g /etc/php5/fpm/php.ini;
mkdir /gluster;
mount -t glusterfs gluster_node_private_ip:/file_store /gluster;
echo «gluster_node_private_ip:/file_store /gluster glusterfs defaults,_netdev 0 0» >> /etc/fstab;
mkdir /gluster/www;
wget https://raw.githubusercontent.com/ryanpq/do-wpc/master/default -O /etc/nginx/sites-enabled/default;
service nginx restart;

На дополнительные ноды нужно установить те же пакеты, смонтировать том GlusterFS и заменить конфигурационный файл Nginx, но не нужно настраивать экземпляр WordPress, поскольку это было сделано при создании первой ноды.

5: Развертывание балансировщика нагрузки

Последним шагом в этом развертывании является создание балансировщика нагрузки. Для этой цели можно использовать еще один сервер Nginx. Чтобы настроить эту ноду, нужно использовать следующий сценарий:

#!/bin/bash
export DEBIAN_FRONTEND=noninteractive;
apt-get update;
apt-get -y install nginx;
lbconf=»
server <
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /usr/share/nginx/html;
index index.php index.html index.htm;
location / <
proxy_pass https://backend;
include proxy_params;
>
>
upstream backend <
ip_hash;
server web_node_1_private_ip
server web_node_2_private_ip
>
»
echo $lbconf > /etc/nginx/sites-enabled/default;
service nginx restart;

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

Затем сценарий установит Nginx:

apt-get update;
apt-get -y install nginx;

После этого он создаст новый конфигурационный файл Nginx в переменной lbconf. Записи для веб-серверов помещаются в раздел upstream backend:

Мастер Йода рекомендует:  Революционная ОС тест на знание Linux

lbconf=»
server <
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /usr/share/nginx/html;
index index.php index.html index.htm;
location / <
proxy_pass https://backend;
include proxy_params;
>
>
upstream backend <
ip_hash;
server web_node_1_private_ip
server web_node_2_private_ip
>
«

После этого в переменной lbconf определяется конфигурационный файл Nginx:

echo $lbconf > /etc/nginx/sites-enabled/default;

Последняя строчка сценария перезапускает Nginx.

6: Настройка DNS

Прежде чем попробовать получить доступ к WordPress в браузере, нужно настроить DNS-запись для этого сайта.

Это можно сделать в панели управления хостингом. Чтобы использовать поддомен www, нужно создать дополнительную запись CNAME.

7: Настройка WordPress

Теперь можно настроить новый сайт WordPress в браузере.

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

8: Автоматизация развертывания

Теперь вы можете выполнить развертывание WordPress без необходимости в ssh-подключении, пора автоматизировать этот процесс с помощью API.

Для этого можно использовать Ruby-скрипт, который запросит у пользователя соответствующие данные, а затем автоматически развернет новый масштабируемый экземпляр WordPress. Вы можете найти подобный скрипт на GitHub.

Заключение

Развертывание масштабируемого приложения WordPress успешно завершено.

WordPress Cluster Installation Guide

WordPress is a highly popular open-source CMS, intended for creation of websites, blogs and apps. This tutorial shows how to deploy a WordPress application into Jelastic platform and configure it as a scalable cluster — such approach ensures high availability and reliability to strengthen your application.

Below, you can find guides for WordPress Cluster installation as:

  • a pre-packaged one-click installation
  • detailed step-by-step manual deployment

WordPress Cluster Automatic Installation

This section explains how to get a ready-to-go WordPress Cluster solution in one click. If you already registered at Jelastic PaaS, package can be installed directly from your dashboard using Jelastic Marketplace .

If you don’t have an account, you can automatically get it and, simultaneously, initiate WordPress Cluster solution installation — just click the Get it hosted now button below and fill the form within the opened page.

As a result you’ll get a new environment with the following topology:

For more details on the WordPress Cluster by Jelastic read the linked article or check the project sources at our JPS collection.

WordPress Cluster Manual Installation

2 replicated MySQL DB servers with Master-Slave replication to enhance cluster performance and contribute its failover

WordPress Deployment

Let’s create a new PHP environment and deploy the latest version of the WordPress application to it.

1. Log in to the Jelastic account with your credentials and navigate to the Environment Topology wizard by clicking the Create environment button.

2. Navigate to the PHP tab, select Apache application server and add the Memcached node. Specify cloudlet limits for your nodes, select the preferable region (if several ones are available) and set the name for your environment.

Click the Create button at the bottom-right corner and wait a minute for environment to be created.

3. Meanwhile, download .zip package from the WordPress official site and upload it to the dashboard within the Deployment manager.


4. Next, initiate deployment of the just uploaded wordpress.zip package to your environment.

Within the opened frame, specify the desired context name or leave it empty (the ROOT one will be used in this case).

Click the Deploy button to start deployment.

5. As a result, you’ll get an environment similar to the following one:

Great! The WordPress package was successfully deployed to your Jelastic environment.

Setup Session Storage

In order to retain all user sessions, we’ll set up the appropriate storage with Memcached node. As a result, in case of a single app server failure, the second one will be able to fetch these backups from Memcached and continue their processing.

1. Click the Config button next to your Apache node. Within the opened Configuration manager, navigate to the etc directory and find the php.ini file.

Within it, enable the memcached module by adding the next string to the Dynamic Extensions section:

2. To activate the support of session storing, scroll down to the session block and add the next lines:

Note: Instead of the placeholder, you should paste the Memcached server IP address — find it by expanding the Additionally list next to this node in your environment.

Don’t forget to Save changes you’ve made by clicking the same-named button.

3. Next, restart your Apache server with the appropriate Restart nodes button next to it.

Once server is up again, all sessions will be safely retained within the Memcached node.

Database Configuration

This step involves creation of two MySQL databases and their configuration to establish the master-slave replication. Such solution will increase the cluster’s performance, security and failover capacity.

1. Configure MySQL cluster according to the appropriate MySQL/MariaDB Database Master-Slave Replication guide.

2. After you’ve completed all of the steps within the linked instruction, navigate to the master DB admin panel and create a new database named wordpress.

Great! Now, we have a separate replicated DB specially for the WordPress application.

WordPress Installation

Once your database and application server are configured, you can proceed with the WordPress installation.

1. Navigate to the Jelastic dashboard and click the Open in browser button next to your environment with WordPress package deployed.

Installation will be started within the new browser tab.

2. The flow is rather simple, therefore let’s pay attention to the database connection settings only. Required fields should be filled up in the following way:

  • Database Name — enter the name of your database (in our case it’s wordpress)
  • Username — specify the username (it is root by default)
  • Password — type your password (the one you’ve received via email)
  • Database Host — paste the link to your master DB without the “https://” protocol and “/” at the end

Table Prefix — change the prefix if you want to run more than one WordPress instance in a single database.

Click Submit to proceed with the WordPress installation.

Cluster Configuration

After successfull installation of the WordPress CMS, we will add the second compute node to the environment topology in order to create cluster.

1. Switch back to the dashboard and click the Change environment topology button next to your main WordPress environment.

2. Add one more Apache application server node by clicking the + button (shown in the image below). Herewith, NGINX load balancer will be fetched automatically.

Click Apply to add nodes.

Tip: With Jelastic you can easily configure automatic horizontal scaling for your WordPress cluster to smartly adjust the amount of application server nodes based on the incoming load.

3. Now, if you open your environment in browser, a ready to work WordPress site will be shown.

That’s all! Your own highly reliable and scalable cluster with WordPress application is now hosted at Jelastic.

Насколько хорошо масштабируется WordPress?

С новым WordPress и его новыми функциями кажется, что WordPress способен намного больше, чем простой движок блога. Но , насколько хорошо используется шкала WordPress, например, 10k -> 100 тыс. Пользователей в день?

С этим большим количеством пользователей большая часть этого будет иметь хорошую стратегию кеша, но насколько хорошо разработан WordPress, чтобы сделать это легко и дать вам необходимый вам контроль. Fx может кэшировать часть страницы и отображать только пользовательские детали, поддерживать настройку db master /slave и т. Д.?

3 ответа

Очевидно, что ничего не масштабируется, а также статические файлы, обслуживаемые быстрым веб-сервером , и любая CMS, которая должна выяснить, что загрузить, а затем загрузить, также не будет работать, WordPress или иначе. Одна из проблем — количество запросов к базе данных, требуемых для каждого запроса URL-адреса, и мой опыт работы с двумя предыдущими годами, работающий исключительно с Drupal, а теперь 2+ года с WordPress заключается в том, что WordPress намного лучше в этом отделе.

Тем не менее почти ничего с любой мощностью собирается масштабировать «вне коробки» ; это все о , что вы можете сделать по мере роста потребностей в масштабируемости?

На нижнем конце «большого количества трафика» есть отличные плагины кэширования и с недорогими CDN , вы можете сделать довольно неплохие работу в ИТ-бюджете и низкий бюджет хостинга. Вот еще некоторые вопросы и amp; ответы на отзыв:

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

Как только узкие места идентифицируются, вы можете сделать локализованную оптимизацию с помощью таких как Transients API . Этот Q & amp; A дает пример, который можно оптимизировать с помощью API Transients и показывает, как:

Если вам действительно хочется вытащить большие пушки , вы можете настроить Memcached , HyperDB , Nginx > и /или больше, чтобы ускорить процесс (кажется, последний действительно развивается, чтобы получить потрясающую масштабируемость из WordPress):

И наконец, существуют новые веб-хосты, ориентированные на WordPress, специализирующиеся на производительности , такие как WP Engine , ZippyKid и другие:

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

По крайней мере, ИМО. 🙂

Не ожидайте многого от общего хостинга — не обвиняйте WordPress в медлительности, если вы находитесь на общем хосте. Общие хосты могут переписывать 1000 пользователей на один сервер. Таким образом, вы можете потратить весь день на оптимизацию счета за 10 долларов США в месяц, и это не имеет значения. Также следите за маркетинговыми словами — просто потому, что он говорит, что «облако» не означает, что вы не используете один сервер с 100 или тысячами людей.

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

Главное, что вы замедляете медленные запросы MySQL и WordPress из коробки, не должны вас беспокоить. Однако мне пришлось «LIMIT» мои комментарии, потому что у меня было 50 000 + комментариев. (Это еще исправлено?) Кроме того, если вы делаете что-либо нетипичное (например, 1000 категорий?), Это тоже может быть проблемой.

Я использую Linode 512 с NginX и «top» показывает, что PHP и NginX выполняют свою работу менее чем за 1/100-й секунды за запрос. Почти все время процессора связано с MySQL. Вы могли бы обслуживать 1 миллион страниц в месяц с $ 20 Linode, но как только вы начнете добавлять плагины и фотографии, я думаю, вам понадобится «1GB» Linode. С моей точки зрения, это в значительной степени линейно: если просмотр страниц двойной, просто удвойте размер вашего Linode.

Отказ от ответственности: я не работаю для Linode.

2 года спустя), так как вы хотите кэшировать части страницы с помощью PHP, вот простое решение, которое я использую на удивление быстро. Я кэширую несколько отдельных частей /частей на страницу в течение 1/100-й секунды. Похоже, что ramdisk может сделать это еще быстрее, но для моих нужд это очень быстро:

В итоге есть 3 вещи, которые замедляют WordPress по шкале, и они сводятся к следующему:

  • Хостинг — вам нужен хороший хост с последним программным обеспечением — все хорошие варианты — PHP 7, Nginx, Varnish, Redis, fail2ban и PerconaDB.
  • Нет сканирования таблиц — многие плагины написаны любительскими кодами, которые даже не знают, что такое сканирование таблицы. Для предотвращения сканирования таблиц необходимы две вещи: полезный индекс и запрос, написанный таким образом, что он может использовать индекс
  • В PHP-петлях нет или мало SQL-запросов. Некоторые плагины явно тестировались на крошечных сайтах, и по той или иной причине они будут проходить через каждый продукт в вашей базе данных и делать новый SQL-запрос для каждого продукта /сообщения. Вы в идеале хотите меньше, чем 100 SQL-запросов на странице — звучит много, но это не так, и с 12 июня 2020, 21:35:14

WP Optimize — оптимизация базы данных и изображений WordPress

Привет, дорогие друзья! Плагин WP Optimize разработан для упрощения вашей повседневной работе с WordPress, то есть, для оптимизации базы данных. Если сказать простым языком, плагин удаляет из вашей базы MySQL всякий не нужный хлам и мусор. Оптимизация базы данных WordPress происходит в автоматическом режиме или по желанию, в ручном режиме. Кликнули мышкой и всё, готово! New ! В плагин добавлена функция сжатие изображений автоматически. Круто!


Оптимизация вордпресс с помощью плагина WP-Optimize

Проект WP-Optimize начался в качестве полезной программки для собственных нужд разработчика. Потом, как пишет автор модуля, он понял, что это программка пригодится многим пользователям, так и произошло. Я например сам по началу не знал, что при написании статьи или при создании страницы, она сохраняется (ревизия) много раз, тем самым база данных увеличивается в размерах. Например, если у вас есть пост, который составляет примерно 100 кб и у вас при сохранении 5 ревизий этой записи, общий размер в пустую составит около 500 кб. В следствии чего накапливается много мусора в базе данных и со временем это даёт значительную нагрузку на сайт/блог. Он начинает тормозить.

Это относится и к спам — комментариям, не одобренным репликам, а так же, и к не нужным нам Tracksbacks и Pingbacks. WP-Optimize может очистить и удалить всё это в один клик мышки.

Плагин WP-Optimize описание

WP-Optimize — эффективный инструмент для автоматической очистки базы данных WordPress, чтобы ваша база данных сайта работала с максимальной эффективностью. Когда вы например, редактируете сообщение или страницу на своем веб-ресурсе, WordPress автоматически сохраняет новую версию в базе данных.

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

Установка WP-Optimize и настройка

Все это делается из админки блога, заходим Плагины — Добавить новый. В поле поиска плагинов вводим название плагина: WP-Optimize. Устанавливаете и активируете его:

Установка и активация плагина

После этого, у вас появится новый раздел WP-Optimize в консоли вордпресс. На странице настроек (русский язык частично), можно включить запланированную очистку и оптимизацию базы данных. Для это нужно отметить нужные пункты и нажмите «Сохранить настройки»:

Настройка плагина по оптимизации базы данных

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

Ревизии записей в вордпресс

Для это, захожу в подраздел Database отмечаю всё, что нужно очистить. Нажимаю синею кнопку «Run all selected optimizations»:

Оптимизация базы данных

Можно не всё сразу очищать, а отдельно, где есть что оптимизировать (смотрите информацию под каждым названием). Напротив пунктов кнопка «Run optimizations», вот на неё и кликаем.

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

Сжатие изображений автоматически

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

Процесс оптимизации изображения выполняется на сторонних серверах с использованием WordPress HTTP API. После сжатия плагин WP-Optimize извлекает оптимизированное изображение и сохраняет его на вашем сайте. В настоящее время функция сжатия использует сервисы от reSmush.it и Nitrosmush (от iSenseLabs). Производительность этих бесплатных сервисов может быть ограничена для больших рабочих нагрузок.

Для настроек оптимизации картинок/фоток перейдите в подраздел images. Пока настройки на английском, но не беда, браузер переведёт:

Настойка сжатие изображений на сайте WordPress

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

Что такое автоматическое сжатие изображений?

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

Оптимизация изображений — в том числе эскизов — проводится в фоновом режиме и за пределами видимости использования. И ещё. Плагин может сжать ваши ранее загруженные изображения. Он покажет вам несжатые картинки которые нужно обработать. Вам надо выделить все показанные фотки (Select all) и нажать кнопку Compressed the selected images:

Показаны несжатые изображения

Теперь, при включенном авто компрессе все ваши вновь загруженные images будут автоматически оптимизированы.

Обратите внимание, что вы можете вручную установить уровень сжатия на Пользовательский и выбрать максимальное сжатие, чтобы Google PageSpeed ​​не ругался на ваши изображения. Вот, как то, так.

До встречи, дорогие друзья. Надеюсь пост был полезен. Удачи.

Вертикальное и горизонтальное масштабирование, scaling для web

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

Возможности для масштабирования для серверов баз данных определяются применяемыми программными решениями: чаще всего это реляционные базы данных (MySQL, Postgresql) или NoSQL (MongoDB, Cassandra и др).

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

Веб-проект обычно начинают на одном сервере, ресурсы которого при росте заканчиваются. В такой ситуации возможны 2 варианта:

  • перенести сайт на более мощный сервер
  • добавить еще один сервер небольшой мощности с объединить машины в кластер

MySQL является самой популярной RDBMS и, как и любая из них, требует для работы под нагрузкой много серверных ресурсов. Масштабирование возможно, в основном, вверх. Есть шардинг (для его настройки требуется вносить изменения в код) и репликация, которая может быть сложной в поддержке.

Вертикальное масштабирование

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

Таким образом с MySQL нужен будет сервер с большим количеством CPU и оперативной памяти, такие сервера имеют значительную стоимость.

Горизонтальное масштабирование
С MongoDB можно добавить еще один средний сервер и полученное решение будет стабильно работать давая дополнительно отказоустойчивость.

Scale-out или горизонтальное масштабирование является закономерным этапом развития инфраструктуры. Любой сервер имеет ограничения и когда они достигнуты или когда стоимость более мощного сервера оказывается неоправданно высокой добавляются новые машины. Нагрузка распределяется между ними. Также это дает отказоустойчивость.

Добавлять средние сервера и настраивать кластеры нужно начинать когда возможности для увеличения ресурсов одной машины исчерпаны или когда приобретение сервера мощнее оказывается невыгодно

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

увеличение или уменьшение масштаба кластера; Scale a cluster in or out

Прочтите этот раздел перед тем, как масштабировать Read this section before you scale

Масштабирование вычислительных ресурсов источника рабочей нагрузки вашего приложения требует преднамеренного планирования. Для разворачивания рабочей среды почти всегда требуется больше часа, поэтому необходимо знать уровень рабочей нагрузки и ее бизнес-контекст. Если вы никогда раньше этого не делали, рекомендуется прочитать и разобраться с рекомендациями по планированию загрузки кластера Service Fabric, прежде чем продолжить чтение оставшейся части этого документа. Scaling compute resources to source your application work load requires intentional planning, will nearly always take longer than an hour to complete for a production environment, and does require you to understand your workload and business context; in fact if you have never done this activity before, it’s recommended you start by reading and understanding Service Fabric cluster capacity planning considerations, before continuing the remainder of this document. Эта рекомендация заключается в том, чтобы избежать непреднамеренных проблем с LiveSite, а также рекомендуется успешно протестировать операции, которые вы решите выполнить в нерабочей среде. This recommendation is to avoid unintended LiveSite issues, and it’s also recommended you successfully test the operations you decide to perform against a non-production environment. В любое время вы можете сообщить о производственных проблемах или запросить платную поддержку Azure. At any time you can report production issues or request paid support for Azure. В этой статье описываются операции масштабирования для инженеров, выделенных для выполнения этих операций, которые обладают соответствующим контекстом, но вы должны понять, какие операции подходят для вашего случая использования, и принять решение. Здесь речь идет о ресурсах для масштабирования (ЦП, хранилище, память), выборе направления масштабирования (вертикальное или горизонтальное) и операций для выполнения (шаблоны развертывания ресурсов, портал, PowerShell/CLI). For engineers allocated to perform these operations that possess appropriate context, this article will describe scaling operations, but you must decide and understand which operations are appropriate for your use case; such as what resources to scale (CPU, Storage, Memory), what direction to scale (Vertically or Horizontally), and what operations to perform (Resource Template deployment, Portal, PowerShell/CLI).

Эта статья была изменена и теперь содержит сведения о новом модуле Az для Azure PowerShell. This article has been updated to use the new Azure PowerShell Az module. Вы по-прежнему можете использовать модуль AzureRM, исправления ошибок для которого будут продолжать выпускаться как минимум до декабря 2020 г. You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Дополнительные сведения о совместимости модуля Az с AzureRM см. в статье Introducing the new Azure PowerShell Az module (Знакомство с новым модулем Az для Azure PowerShell). To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Инструкции по установке модуля Az см. в статье об установке Azure PowerShell. For Az module installation instructions, see Install Azure PowerShell.

Масштабирование кластера Service Fabric с помощью правил автомасштабирования или вручную Scale a Service Fabric cluster in or out using auto-scale rules or manually

Наборы масштабирования виртуальных машин относятся к вычислительным ресурсам Azure. Их можно использовать для развертывания коллекции виртуальных машин и управления ею как набором. Virtual machine scale sets are an Azure compute resource that you can use to deploy and manage a collection of virtual machines as a set. Каждый тип узла, определенный в кластере Service Fabric, настроен как отдельный набор масштабирования виртуальных машин. Every node type that is defined in a Service Fabric cluster is set up as a separate virtual machine scale set. Каждый тип узла поддерживает возможность независимого масштабирования, имеет разные наборы открытых портов и собственные метрики емкости. Each node type can then be scaled in or out independently, have different sets of ports open, and can have different capacity metrics. Дополнительные сведения см. в документе типы узлов Service Fabric . Read more about it in the Service Fabric node types document. Так как типы узлов Service Fabric в кластере состоят из масштабируемых наборов виртуальных машин в серверной части, необходимо настроить правила автомасштабирования для каждого типа узла или масштабируемого набора виртуальных машин. Since the Service Fabric node types in your cluster are made of virtual machine scale sets at the backend, you need to set up auto-scale rules for each node type/virtual machine scale set.

Ваша подписка должна включать в себя достаточное количество ядер для добавления виртуальных машин IaaS, которые войдут в состав этого кластера. Your subscription must have enough cores to add the new VMs that make up this cluster. В настоящее время проверка модели не предусмотрена, поэтому в случае, если лимиты квоты будут нарушены, во время развертывания произойдет сбой. There is no model validation currently, so you get a deployment time failure, if any of the quota limits are hit. Также один тип узла не может превышать 100 узлов на VMSS. Also a single node type can not simply exceed 100 nodes per VMSS. Возможно, придется добавить масштабируемый набор виртуальных машин для достижения целевого масштаба, но автоматическое масштабирование не может автоматически добавлять масштабируемый набор виртуальных машин. You may need to add VMSS’s to achieve the targeted scale, and auto-scaling can not automagically add VMSS’s. Добавление масштабируемых наборов виртуальных машин в динамический кластер является непростой задачей. Обычно это приводит к тому, что пользователи подготавливают новые кластеры, указывая нужные типы узлов при их создании, соответственно планируя загрузку кластера. Adding VMSS’s in-place to a live cluster is a challenging task, and commonly this results in users provisioning new clusters with the appropriate node types provisioned at creation time; plan cluster capacity accordingly.

Выбор типа узла или масштабируемого набора виртуальных машин для масштабирования Choose the node type/Virtual Machine scale set to scale

Сейчас настроить правила автомасштабирования для масштабируемых наборов виртуальных машин с помощью портала для создания кластера Service Fabric нельзя, поэтому мы используем Azure PowerShell (версии 1.0 или более поздней), чтобы получить список типов узлов и добавить к ним правила автомасштабирования. Currently, you are not able to specify the auto-scale rules for virtual machine scale sets using the portal to create a Service Fabric Cluster, so let us use Azure PowerShell (1.0+) to list the node types and then add auto-scale rules to them.

Чтобы получить список масштабируемых наборов виртуальных машин в составе кластера, выполните следующие командлеты: To get the list of virtual machine scale set that make up your cluster, run the following cmdlets:

Задание правил автоматического масштабирования для типа узла или масштабируемого набора виртуальных машин Set auto-scale rules for the node type/virtual machine scale set

Если в кластере есть несколько типов узлов, повторите эти действия для каждого типа узла или масштабируемых наборов виртуальных машин, которые необходимо масштабировать (в или из них). If your cluster has multiple node types, then repeat this for each node types/virtual machine scale sets that you want to scale (in or out). Перед настройкой автомасштабирования обратите внимание на необходимое количество узлов. Take into account the number of nodes that you must have before you set up auto-scaling. Минимальное количество узлов, необходимое для основного типа узлов, зависит от выбранного уровня надежности. The minimum number of nodes that you must have for the primary node type is driven by the reliability level you have chosen. См. дополнительные сведения об уровнях надежности. Read more about reliability levels.


Уменьшение масштаба типа первичного узла до уровня ниже минимального приведет к нестабильности или сбою кластера. Scaling down the primary node type to less than the minimum number make the cluster unstable or bring it down. Это может вызвать потерю данных в приложениях или системных службах. This could result in data loss for your applications and for the system services.

В настоящее время функция автомасштабирования не зависит от уровня нагрузки, который приложения сообщают Service Fabric. Currently the auto-scale feature is not driven by the loads that your applications may be reporting to Service Fabric. В связи с этим автомасштабирование регулируется исключительно счетчиками производительности, которые отправляются каждым экземпляром масштабируемого набора виртуальных машин. So at this time the auto-scale you get is purely driven by the performance counters that are emitted by each of the virtual machine scale set instances.

В сценарии уменьшения масштаба, если тип узла не имеет уровня устойчивости золотого или серебристого, необходимо вызвать командлет Remove-ServiceFabricNodeState с соответствующим именем узла. In a scale down scenario, unless your node type has a durability level of Gold or Silver you need to call the Remove-ServiceFabricNodeState cmdlet with the appropriate node name. Для устойчивости к бронзовой не рекомендуется изменять масштаб более чем одного узла за раз. For the Bronze durability, it’s not recommended to scale down more than one node at a time.

Добавление виртуальных машин в тип узла или масштабируемый набор виртуальных машин вручную Manually add VMs to a node type/virtual machine scale set

При развертывании вы добавляете дополнительные экземпляры виртуальных машин в масштабируемый набор. When you scale out, you add more virtual machine instances to the scale set. Эти экземпляры становятся узлами, которые использует Service Fabric. These instances become the nodes that Service Fabric uses. Службе Service Fabric известно, когда в масштабируемый набор добавляются экземпляры (путем развертывания), и она реагирует автоматически. Service Fabric knows when the scale set has more instances added (by scaling out) and reacts automatically.

Добавление виртуальных машин занимает некоторое время, поэтому не следует ждать мгновенного добавления. Adding VMs takes time, so do not expect the additions to be instantaneous. Таким образом, необходимо заранее добавить емкость, чтобы в течение 10 минут можно было получить доступ к виртуальной машине для размещения реплик или экземпляров службы. So plan to add capacity well in advance, to allow for over 10 minutes before the VM capacity is available for the replicas/service instances to get placed.

Добавление виртуальных машин с помощью шаблона Add VMs using a template

Следуйте указаниям в коллекции шаблонов быстрого запуска, чтобы изменить число виртуальных машин в каждом типе узла. Follow the sample/instructions in the quickstart template gallery to change the number of VMs in each node type.

Добавление виртуальных машин с помощью PowerShell или команд интерфейса командной строки Add VMs using PowerShell or CLI commands

Следующий код получает масштабируемый набор по имени и увеличивает значение емкости масштабируемого набора на 1. The following code gets a scale set by name and increases the capacity of the scale set by 1.

Этот код задает значение 6 для емкости. This code sets the capacity to 6.

Удаление виртуальных машин из типа узла или масштабируемого набора виртуальных машин вручную Manually remove VMs from a node type/virtual machine scale set

При масштабировании в типе узла удаляются экземпляры виртуальных машин из масштабируемого набора. When you scale in a node type, you remove VM instances from the scale set. Если тип узла является бронзовым уровнем устойчивости, Service Fabric не знает, что произошло, и сообщает о том, что узел отсутствовал. If the node type is Bronze durability level, Service Fabric is unaware what has happened and reports that a node has gone missing. Затем Service Fabric сообщает о неработоспособном состоянии кластера. Service Fabric then reports an unhealthy state for the cluster. Чтобы предотвратить это неправильное состояние, необходимо явным образом удалить узел из кластера и удалить состояние узла. To prevent that bad state, you must explicitly remove the node from the cluster and remove the node state.

Системные службы Service Fabric выполняются в типе первичного узла в кластере. The service fabric system services run in the primary node type in your cluster. При масштабировании типа первичного узла никогда не следует уменьшать количество экземпляров до меньшего уровня надежности . When scaling down the primary node type, never scale down the number of instances to less than what the reliability tier warrants.

Для службы с отслеживанием состояния необходимо определенное количество узлов, которые постоянно доступны и работают, чтобы поддерживать доступность этой службы и сохранять ее состояние. For a stateful service, you need a certain number of nodes to be always up to maintain availability and preserve state of your service. Требуется как минимум количество узлов, равное количеству целевых наборов реплик секции или службы. At the very minimum, you need the number of nodes equal to the target replica set count of the partition/service.

Удаление узла Service Fabric Remove the Service Fabric node

Действия по удалению состояния узла вручную применяются только к типам узлов с уровнем устойчивости бронзовой. The steps for manually removing node state apply only to node types with a Bronze durability tier. Для уровня устойчивости » серебро » и » Gold » эти действия выполняются автоматически платформой. For Silver and Gold durability tier, these steps are done automatically by the platform. Дополнительные сведения о устойчивости см. в статье Service Fabric планирование емкости кластера. For more information about durability, see Service Fabric cluster capacity planning.

Чтобы обеспечить равномерное распределение узлов кластера между доменами сбоя и обновления, включив тем самым их сбалансированное использование, необходимо сначала удалить последний созданный узел. To keep the nodes of the cluster evenly distributed across upgrade and fault domains, and hence enable their even utilization, the most recently created node should be removed first. Другими словами, необходимо удалить узлы в порядке, обратном порядку их создания. In other words, the nodes should be removed in the reverse order of their creation. Последний созданный узел — это узел с максимальным значением свойства virtual machine scale set InstanceId . The most recently created node is the one with the greatest virtual machine scale set InstanceId property value. В примерах кода ниже возвращается последний созданный узел. The code examples below return the most recently created node.

Кластеру Service Fabric необходимо сообщить, что этот узел будет удален. The Service Fabric cluster needs to know that this node is going to be removed. Для этого нужно выполнить три шага: There are three steps you need to take:

Отключить узел, чтобы он больше не использовался для репликации данных. Disable the node so that it no longer is a replicate for data.
PowerShell: Disable-ServiceFabricNode PowerShell: Disable-ServiceFabricNode
sfctl: sfctl node disable sfctl: sfctl node disable

Остановить узел, после чего работа среды выполнения Service Fabric будет полностью завершена и ваше приложение получит запрос на завершение. Stop the node so that the Service Fabric runtime shuts down cleanly, and your app gets a terminate request.
PowerShell: Start-ServiceFabricNodeTransition -Stop PowerShell: Start-ServiceFabricNodeTransition -Stop
sfctl: sfctl node transition —node-transition-type Stop sfctl: sfctl node transition —node-transition-type Stop

Удалить узел из кластера. Remove the node from the cluster.
PowerShell: Remove-ServiceFabricNodeState PowerShell: Remove-ServiceFabricNodeState
sfctl: sfctl node remove-state sfctl: sfctl node remove-state

После применения этих шагов узел можно удалить из масштабируемого набора. Once these three steps have been applied to the node, it can be removed from the scale set. Если вы используете любой уровень устойчивости, помимо бронзовой, эти действия выполняются при удалении экземпляра масштабируемого набора. If you’re using any durability tier besides bronze, these steps are done for you when the scale set instance is removed.

Следующий блок кода получает последний созданный узел, отключает, останавливает и удаляет его из кластера. The following code block gets the last created node, disables, stops, and removes the node from the cluster.

В коде sfctl ниже следующая команда используется для получения значений имени узла последнего созданного узла: sfctl node list —query «sort_by(items[*], &name)[-1].name» In the sfctl code below, the following command is used to get the node-name value of the last-created node: sfctl node list —query «sort_by(items[*], &name)[-1].name»

Используйте следующие запросы sfctl, чтобы проверить состояние каждого шага. Use the following sfctl queries to check the status of each step

Проверка состояния деактивации sfctl node list —query «sort_by(items[*], &name)[-1].nodeDeactivationInfo» Check deactivation status sfctl node list —query «sort_by(items[*], &name)[-1].nodeDeactivationInfo»

Проверка состояния остановки sfctl node list —query «sort_by(items[*], &name)[-1].isStopped» Check stop status sfctl node list —query «sort_by(items[*], &name)[-1].isStopped»

Свертывание масштабируемого набора Scale in the scale set

Теперь, когда узел Service Fabric удален из кластера, можно свернуть масштабируемый набор виртуальных машин. Now that the Service Fabric node has been removed from the cluster, the virtual machine scale set can be scaled in. В приведенном ниже примере емкость масштабируемого набора уменьшается на 1. In the example below, the scale set capacity is reduced by 1.

Этот код задает значение 5 для емкости. This code sets the capacity to 5.

Возможные варианты поведения в обозревателе Service Fabric Behaviors you may observe in Service Fabric Explorer

При вертикальном масштабировании кластера в Service Fabric Explorer отражается число узлов (экземпляров масштабируемых наборов виртуальных машин), которые входят в кластер. When you scale up a cluster the Service Fabric Explorer will reflect the number of nodes (virtual machine scale set instances) that are part of the cluster. Тем не менее при уменьшении масштаба кластера удаленный узел или экземпляр виртуальной машины будет отображаться как неработоспособный, если не вызвать командлет Remove-ServiceFabricNodeState с именем соответствующего узла. However, when you scale a cluster down you will see the removed node/VM instance displayed in an unhealthy state unless you call Remove-ServiceFabricNodeState cmd with the appropriate node name.

Вот как объясняется это поведение. Here is the explanation for this behavior.

Узлы, перечисленные в Service Fabric Explorer, отражают то, что системным службам Service Fabric (в частности FM) известно о числе узлов в кластере. The nodes listed in Service Fabric Explorer are a reflection of what the Service Fabric system services (FM specifically) knows about the number of nodes the cluster had/has. При уменьшении масштабируемого набора виртуальных машин виртуальная машина удаляется, но системная служба диспетчера отработки отказов по-прежнему считает, что узел (который был сопоставлен с удаленной виртуальной машиной) вернется. When you scale the virtual machine scale set down, the VM was deleted but FM system service still thinks that the node (that was mapped to the VM that was deleted) will come back. В связи с этим Service Fabric Explorer продолжает отображать этот узел (хотя состояние работоспособности может быть ошибочным или неизвестным). So Service Fabric Explorer continues to display that node (though the health state may be error or unknown).

Проверить удаление узла при удалении виртуальной машины можно двумя способами: In order to make sure that a node is removed when a VM is removed, you have two options:

Выбрать уровень надежности Gold или Silver для типов узлов в кластере — это обеспечит интеграцию инфраструктуры. Choose a durability level of Gold or Silver for the node types in your cluster, which gives you the infrastructure integration. При уменьшении масштаба узлы будут удаляться из состояния системных служб (FM) автоматически. Which will then automatically remove the nodes from our system services (FM) state when you scale down. Дополнительные сведения об уровнях надежности см. здесь. Refer to the details on durability levels here

После уменьшения масштаба экземпляра виртуальной машины необходимо вызвать командлет Remove-ServiceFabricNodeState. Once the VM instance has been scaled down, you need to call the Remove-ServiceFabricNodeState cmdlet.

Для постоянной работы кластеров Service Fabric требуется определенное количество узлов, чтобы все время поддерживать доступность и сохранять состояние, которое называется «поддержание кворума». Service Fabric clusters require a certain number of nodes to be up at all the time in order to maintain availability and preserve state — referred to as «maintaining quorum.» Поэтому обычно не рекомендуется завершать работу всех компьютеров в кластере, пока не будет выполнена полная архивация состояния, так как это может быть небезопасно. So, it is typically unsafe to shut down all the machines in the cluster unless you have first performed a full backup of your state.

Следующие шаги Next steps

Дополнительные сведения о планировании емкости кластера, обновлении кластера и секционировании служб см. в следующих статьях: Read the following to also learn about planning cluster capacity, upgrading a cluster, and partitioning services:

How to: Setting up a WordPress cluster for huge sites

If you have a huge site, chances are you also do a lot of data processing – imports, exports, calculations etc.

These kind of batch processing jobs that max out the CPU and disk are the mortal enemy of real-time transactions. Your web visitors demand real-time interaction and fast response from your site, so if you are running imports and maxing out your CPU and disk on the same server hosting your web traffic then your users are regularly going to encounter slowness. This leads to loss of interest from your visitors, loss of sales and loss of SEO rank.

Ultimately, to solve this, you need to architect a better solution – you need to separate the batch processing from the realtime stuff. That means you need a minimum of 2 servers. 1 server processes all the data imports, exports, calculations, category counts, etc – the data is replicated to the 2nd server and that server serves your web traffic.

If you’re going to the bother of getting 2 servers, you’re better off going further and getting 3 servers. It’s very little extra hassle and then gives you the ability to have 3 servers online at once with no batch processing, or 1 or 2 of the servers handling batch processing and the remaining ones serving web traffic.

Using this model, you can also easily switch servers offline to upgrade them without interrupting visitors to your website. That means you can be online 100% of the time!

Note that this setup technically uses 4 servers – the 4th server being a load balancer. Instead of this server, you could use the Digital Ocean load balancer feature/server instead but I provide details below for installing this easily.

If you’re looking at building a cluster for more speed, you may find our plugin pack will help give you the speed boost you need.

Step by step guide to building your cluster

This is the guide I use to install these clusters, so hopefully it helps some of you out there who wish to go huge with your WordPress sites.

Create 3 Ubuntu 16.04 servers

I like Digital Ocean, so this guide is using their hosting, but you can use any host provided they offer private networking and Ubuntu 16.04.

Create 3 Ubuntu 16.04 (or 3 servers on any platform) – they make it easy to make multiple at once – make sure to enable private networking and add your ssh key.

Install PerconaDB XtraDB Cluster on your cluster-nodes

Log into your 3 droplets and run the following commands on each node:

Note: You will be asked to enter a new root password for the cluster. To make life easier, use the same password for each PerconaDB node, or leave the root password blank and it will infer security if you log in as root and connect.

Configure private networking


We want the nodes to share data over the private network, rather than out and in from your hosting company. This prevents crazy bandwidth costs, speeds things up and improves security.

Even though private networking is already enabled, we need to be able to reliably use eth1 (rather than eth0) as the private network device.

On each node edit the grub networking file. I prefer vi to edit files, but you can use nano or even edit the files with Filezilla.

Find the line that begins GRUB_CMDLINE_LINUX_DEFAULT and alter it as follows (add net.ifnames=0):

Save the file then run the update grub command and reboot (only time I know of where you need to reboot a linux box!).

Repeat the above for all your nodes. Then you can check config with this:

You should see the public IP address against eth0 and the private address against eth1.

You can also view each ethernet devices configuration here:

The file above will already be configured if you selected private networking when you created the droplet.

Take a note of the private IP address for each of your 3 nodes. This information is also available from your Digital Ocean interface when you click through to each droplet.

You can test private networking is working by pinging the private IP address of another node from one of the nodes:

Configure replication

Firstly, we need a replication user. Create this user on all 3 nodes.

or if you chose a password for your mysql server earlier, use this:

Enter the root DB password you chose earlier then create a new user for replication purposes (choose a strong password and note it down so we can add it to the configuration files):

Next exit MySQL by typing ‘exit’ then hitting enter, then stop MySQL on all 3 nodes using:

On node1, customise the configuration file below according to your private IP addresses and replication user password enter it into this file:

  1. Enter the 3 private IP addresses for wsrep_cluster_address, separated by commas.
  2. Enter node 1 private IP address for wsrep_node_address.
  3. Enter the sst password for wsrep_sst_auth.
  4. Change the name of the node on the line wsrep_node_name

Your file will end up looking something like this (lines in bold are the lines you need to alter from the default config):

Note: You will also need to remove the # comment from the beginning of the lines with the wsrep_node_address and the wsrep_sst_auth.

Copy the contents of the file and then save it. Configure node 2 and node 3 by editing the same file on those nodes and altering 2 rows from the file above:

  1. Change wsrep_node_address to be the private IP address of node 2 (or node 3 for that node)
  2. Change wsrep_node_name to pxc-cluster-node-2 or pxc-cluster-node-3

Once you’ve done this, you’re ready to bootstrap your cluster.

Bootstrap your cluster

On node 1, run the following command:

Check it’s running by logging into mysql and running this command:

Note: The above command can be useful in future to check for replication status – you can see things like how many items are queued to be replicated amongst other details.

On node 2 and 3, run the following:

You now have a Percona cluster with 3 nodes replicating data to each other.

Install Nginx and PHP 7 on all 3 nodes

On each node, install Nginx and PHP 7 using the following sequence of commands:

A faster way to run all of the above would be using this single line:

apt-get install -y nginx php7.0 php7.0-curl php7.0-gd php7.0-intl php7.0-mysql php-memcached php7.0-mbstring php7.0-zip php7.0-xml php7.0-mcrypt unzip

Install GlusterFS for file replication

GlusterFS gives us the guarantee that all nodes see the same files. In the configuration below, each node will have a full copy of all the files from the other nodes, BUT if you decide to expand this outwards, you will start seeing space savings. For example, if your WordPress files take up 90GB then with 3 nodes, 90GB will be used per node.

If you had 9 nodes, then each node would only be using 30GB to store 90GB across the entire GlusterFS.

The way to think about this is that across the GlusterFS file network, there are 3 copies of each file for redundancy purposes. Then if 1 node is removed from the GlusterFS cluster, files will be copied to other nodes to bring the cluster back up to having triplicate redundancy.

Run the following commands on each node:

Then run the following commands on node 1, adjusting the IP addresses to be the private IP addresses of node 2 and node 3 in your network:

Then create a gluster volume by running the command below with IP addresses altered to the private IP addresses of node 1, 2 and 3 in your network:

Note: You can reduce the replica number if you want a faster file system but redundancy will be lowered. For example, with a 4-node configuration, replica 2 will mean 2 of the nodes can die and you can still rebuild your filesystem. If 3 die, you are out of luck. Here is an example 4 node config:

You can find out more about the commands available here:

Then on each node, create a folder and mount that folder, linking it to the glustervolume:

You now have a glusterfs redundant file cluster where we can install WordPress.

Install Unison for file replication

After much testing, GlusterFS is not well-suited to WordPress file-replication. GlusterFS slows down a LOT when there are a lot of files in each directory. The guide has been updated to use Unison instead. This Unison setup uses a star schema for file replication, with node 1 at the centre of the star.

That means a file edit on node 3 will replicate to node 1 and then to node 2. A file edit on node 1 will replicate out directly to node 2 and 3. Because of this, it makes sense to make node 1 our wp-admin server where we upload plugin files. Because of this star schema for file replication, node 1 is your most important node. If it goes down, or you switch it off, file replication will be paused until you bring it back online.

On each node, install unison:

This will allow us to run the replication commands later once we have installed the WordPress files.

Configure SSH so nodes can connect to each other

SSH access is required for Unison to be able to replicate files. Run the following on all 3 nodes:

Hit enter 3 times to accept 3 defaults inc 2 blank passwords for the keyfile so it works non-interactively
Now, grab a copy of the id_rsa.pub files for each node and paste them into the other 2 nodes authorized_keys file. Find the public keys of each node by running this command:

Then paste those public keys into the authorized_keys file of the other 2 nodes:

Authenticate each node

ssh ipofnode2
ssh ipofnode3


You will be asked if you wish to trust the other node. Answer yes.

Repeat this on node 2 and node 3, connecting to the other 2 nodes.

Replicate the web folder files using Unison

Now that we have ssh authentication, we can set up Unison to replicate the website files to node 2 and 3. Run the following commands on node 1 of your cluster:

Note: replace the IP addresses with your own and the folder names with your own.

Since you have no files yet in /var/www these commands will complete quickly.

Now set up a crontab/cron job for Unison. Run the following command:

Choose whatever editor you prefer when it asks you then append the following to the end of the file:

Change IP addresses and folder locations. Use internal IP addresses so traffic goes over the faster internal network card.

Install WordPress files onto Node 1 only

Because we are using file replication and we already have database replication in our cluster, we only need to install WordPress onto node 1. On node 1, run the following:

Note: Instead of /var/www/wpicluster you could use /var/www/yourdomain.com but if you do, ensure you alter the nginx config files in the next section.

Configure Nginx to load your WordPress site on each node

I’ve created some configuration files to make this part quicker and easier. The configuration files set Nginx up to work over port 80 – later, we will add SSL to our load balancer. This reduces load on our servers since they won’t have to decrypt SSL traffic.

The configuration files here also configure the Nginx fastcgi-cache, so you don’t need to install Varnish. They’re also domain-name independent, so no configuration required.

On all 3 nodes, run the following commands:

Set up your Load Balancer

Digital Ocean provide a load balancer, but with that approach you have to manually renew your SSL certificates. Plus you get less control – we want control so we can send wp-admin traffic to node 1. So follow the instructions below to set up your own load balancer.

First, create a droplet with Ubuntu 16.04 again, private networking and your SSH keys.

Then log onto your load balancer droplet and run the following commands:

Then create a new file at /etc/nginx/conf.d/loadbalancer.conf.

This will automatically be loaded when you restart nginx. Enter the following in the file, adjusted for your private IP addresses.

SaveNow, log into your DNS provider and point your new domain name at the public IP address of your loadbalancer node.

Configure WordPress

Now that we have database and file replication set up, and a load balancer, we can go about starting the 5-minute install of WordPress.

On node 1, connect to mysql using:

Note: you’ll be asked for your password, so paste it in – right-click in putty is paste, and it’ll look like nothing happened because it’s a password field, but it does paste.

Visit the URL you chose earlier for your loadbalancer, e.g. https://www.yourdomain.com.

Choose your language, then enter the database name: wpicluster, the username: wpi and the password you chose in the GRANT command above.

Set up WordPress Cron on only node 1

WP Cron is awful. It relies on users visiting your site in order to run scheduled tasks. In this case, we don’t even want scheduled jobs running on node 2 or 3, so we’ll disable wp cron across all nodes and then implement a real cron job on node 1.

On node 1, edit /var/www/wpicluster/wp-config.php. This file edit will replicate to your other nodes.

and insert the following lines somewhere:

Note: Only the first line is to disable WP_CRON. The rest is for later when we forward traffic from our load balancer and we want to ensure WordPress knows to server up static files over HTTPS if that was what the user requested.

If you’re struggling to figure out where to put this code, you can stick it after the define(‘DB_NAME’, ….); line.

This wp-config.php update will replicate out to the other nodes using GlusterFS, so you don’t need to modify this on the other nodes.

And add an extra line as follows:

Set up SSL on your load balancer

Now get your free SSL certificates from LetsEncrypt. On your load balancer node, run the following:

You should get a note telling you CONGRATULATIONS. It will also tell you the location the key files were saved to. Now edit the loadbalancer.conf file from earlier to set up SSL. (WordPress installation does not work well over SSL which is why we add SSL after installation)

Uncomment the ssl_certificate (x2) and ssl_certificate_key (x2) lines and replace the path with the paths provided by the output from LetsEncrypt.

Also uncomment the line “return 301 https://$host$request_uri;”

Once you have edited the loadbalancer.conf file and restarted nginx, you will have a working SSL certificate on your load balancer.

Note: At this point, if you access your website with https, some CSS will appear broken. There is one final stage we have to complete in order to fix this, which is almost the final step in the entire process.

Update your Site URL in WordPress

Log into node1.yourdomain.com. Visit the WordPress dashboard, then Settings->General.

You will see 2 domain entries, both of which are probably currently tied to your node 1 subdomain, and both of which will be http instead of https.

Replace both of these entries with https://www.yourdomain.com.

Note: Here you enter the domain name you chose for your load balancer, normally www.yourdomain.com or similar.

If you didn’t already, edit your wp-config.php file on Node 1 and just below where you disabled WP_CRON, add the following lines:

The traffic is being served over https to your users, but because it’s plain http on each node (between your load balancer and your nodes), you need to make sure WordPress knows it’s HTTPS so any static files are correctly loaded over HTTPS.

Go forth and conquer!

That’s it, a mammoth task complete.

You can visit wp-admin from any server, but you can also force traffic to node 1 for your own admin purposes by visiting https://www.yourdomain.com:9443/wp-admin/. With the configuration above, node 1 is never serving traffic to front-end users, so you can run all kinds of admin jobs on there without impacting slowing down user traffic.

If anyone has any questions, fire away!

Dave Hilditch

I’m the owner of WP Intense. I code plugins to help with performance and automation and I write stack-building guides.

Chat to me directly through our on-site chat bubble.

Мастер Йода рекомендует:  Чем ссылка глубже - тем она лучше
Добавить комментарий