Управление и мониторинг сайтов Drupal в Windows Azure

• Диагностические данные Windows Azure.

• Пользовательские скрипты мониторинга.

• System Center Operations Manager.

• Сторонние инструменты, такие как Azure Diagnostics Manager и Azure Storage Explorer .

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

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

<DiagnosticMonitorConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration" 
                                configurationChangePollInterval="PT1M" 
                                overallQuotaInMB="4096">
  
  <DiagnosticInfrastructureLogs bufferQuotaInMB="10"
                                scheduledTransferLogLevelFilter="Error"
                                scheduledTransferPeriod="PT1M" />
 
  <Logs bufferQuotaInMB="0"
        scheduledTransferLogLevelFilter="Verbose"
        scheduledTransferPeriod="PT1M" />
 
  <Directories bufferQuotaInMB="0" scheduledTransferPeriod="PT5M">
    <!-- These three elements specify the special directories that are set up for the log types -->
    <CrashDumps container="wad-crash-dumps" directoryQuotaInMB="256" />
    <FailedRequestLogs container="wad-frq" directoryQuotaInMB="256" />
    <IISLogs container="wad-iis" directoryQuotaInMB="256" />
  </Directories>
 
  <PerformanceCounters bufferQuotaInMB="0" scheduledTransferPeriod="PT1M">
    <!-- The counter specifier is in the same format as the imperative diagnostics configuration API -->
    <PerformanceCounterConfiguration counterSpecifier="\Memory\Available MBytes" sampleRate="PT10M" />
    <PerformanceCounterConfiguration counterSpecifier="\Network Interface(*)\Bytes Total/sec" sampleRate="PT10M" />
    <PerformanceCounterConfiguration counterSpecifier="\Processor(*)\% Processor Time" sampleRate="PT10M" />
    <PerformanceCounterConfiguration counterSpecifier="\System\Processor Queue Length" sampleRate="PT10M" />
    <PerformanceCounterConfiguration counterSpecifier="\Web Service(_Total)\Current Connections" sampleRate="PT10M" />
    <PerformanceCounterConfiguration counterSpecifier="\Web Service(_Total)\Bytes Total/sec" sampleRate="PT10M" />
    <PerformanceCounterConfiguration counterSpecifier="\Web Service(_Total)\Connection Attempts/sec" sampleRate="PT10M" />
    <PerformanceCounterConfiguration counterSpecifier="\Web Service(_Total)\Get Requests/sec" sampleRate="PT10M" />
    <PerformanceCounterConfiguration counterSpecifier="\Web Service(_Total)\Files Sent/sec" sampleRate="PT10M" />
  </PerformanceCounters>
 
  <WindowsEventLog bufferQuotaInMB="0"
                   scheduledTransferLogLevelFilter="Verbose"
                   scheduledTransferPeriod="PT5M">
 
    <!-- The event log name is in the same format as the imperative diagnostics configuration API -->
 
    <DataSource name="System!*" />
 
  </WindowsEventLog>
 
</DiagnosticMonitorConfiguration>

Дополнительные сведения о настройке файлов конфигурации диагностики см. В разделе Как использовать файл конфигурации диагностики Windows Azure . Эта информация хранится локально в каждом экземпляре роли и затем передается в хранилище Windows Azure по заданному расписанию или по требованию. См. Начало работы с хранением и просмотром диагностических данных в хранилище Windows Azure . Различные инструменты мониторинга, такие как Azure Diagnostics Manager , помогут вам легче анализировать диагностические данные.

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

Задачи резервного копирования

Чтобы оставаться высокодоступным, важно сделать резервную копию ваших данных в качестве стратегии глубокой защиты для аварийного восстановления. Это действительно так, хотя в SQL Azure и Windows Azure Storage реализована избыточность для предотвращения потери данных. Одна из очевидных причин заключается в том, что эти службы не могут предотвратить ошибку администратора, если данные были случайно удалены или неправильно изменены.

В SQL Azure в настоящее время нет технологии формального резервного копирования, хотя существует множество сторонних инструментов и решений, обеспечивающих эту возможность. Обычно размер базы данных для сайта Drupal относительно невелик. В случае SAG Awards это было всего ~ 100-150 МБ. Таким образом, выполнение полного резервного копирования с использованием любой стратегии было относительно быстрым. Если ваша база данных намного больше, вам, возможно, придется протестировать различные стратегии резервного копирования, чтобы найти ту, которая работает лучше всего.

Помимо сторонних решений для резервного копирования SQL Azure, существует несколько стратегий получения резервной копии ваших данных:

· Используйте инструмент Drush и команду portabledb-export .

Периодически копировать базу данных с помощью команды CREATE DATABASE Transact-SQL .

· Использование приложений уровня данных (DAC) для резервного копирования и восстановления базы данных.

Методы резервного копирования и защиты данных SQL Azure более подробно описаны в разделе « Непрерывность бизнеса в SQL Azure» .

Обратите внимание, что затраты на пропускную способность накапливаются при выполнении любой операции резервного копирования, которая передает информацию за пределы центра данных Windows Azure. Чтобы сократить расходы, вы можете скопировать базу данных в базу данных в том же центре данных. Или вы можете экспортировать приложения уровня данных в хранилище BLOB-объектов в том же центре данных.

Другая потенциальная задача резервного копирования включает файлы в хранилище BLOB-объектов. Если вы храните главную копию всех мультимедийных файлов, загруженных в хранилище BLOB-объектов, то у вас уже есть локальная резервная копия этих файлов. Однако если несколько администраторов загружают файлы в хранилище BLOB-объектов для использования на сайте Drupal, рекомендуется перечислить учетную запись хранилища и загрузить любые новые файлы в центральное место. Следующий скрипт PHP демонстрирует, как это можно сделать путем резервного копирования всех файлов в хранилище BLOB-объектов после указанной даты изменения.

<?php
/**
* Backup the blob storage to a local folder 
* 
* PHP version 5.3
* 
* @category Blob Backup
* @package Windows Azure
* @author Bibin Kurian
* @copyright 2011 Microsoft Corp. (http://www.microsoft.com)
* @license New BSD license, (http://www.opensource.org/licenses/bsd-license.php)
* @version SVN: 1.0
* @link
* 
*/
 
/** Microsoft_WindowsAzure_Storage_Blob */
require_once 'Microsoft/WindowsAzure/Storage/Blob.php';
 
//Windows Azure BLOB storage account name
define("AZURE_STORAGE_ACCOUNT", "YOUR_ACCOUNTNAME");
 
//Windows Azure BLOB storage container name
define("AZURE_STORAGE_CONTAINER", "YOUR_STORAGECONTAINERNAME");
 
//Windows Azure BLOB storage secret key
define(
    "AZURE_STORAGE_KEY", 
    "YOUR_SECRETKEY"
);
 
//backup folder
define("STORAGE_BACKUP_DIR", "YOUR_LOCALDRIVE");
 
//backup from date
define("DEFAULT_BACKUP_FROM_DATE", strtotime("Mon, 19 Dec 2011 22:00:00 GMT"));
 
//backup to date
define("DEFAULT_BACKUP_TO_DATE", time());
 
//directory seperator
define("DS", "\\");
 
//start backup logic
 
//current datetime to create the backup folder
$now = date("F j, Y, g.i A");
$fullBackupDirPath = STORAGE_BACKUP_DIR . DS . $now . DS. AZURE_STORAGE_CONTAINER;
mkdir($fullBackupDirPath, 0755, true);
 
//For the directory creations, pointing the current directory to user specified directory
chdir($fullBackupDirPath);
 
//BLOB object
$blobObj = new Microsoft_WindowsAzure_Storage_Blob(
    'blob.core.windows.net', 
    AZURE_STORAGE_ACCOUNT,
    AZURE_STORAGE_KEY
);
 
//$blobObj->setProxy(true, 'YOUR_PROXY_IF_NEEDED', 80);
 
$blobs = (array)$blobObj->listBlobs(AZURE_STORAGE_CONTAINER, '', '', 35000);
backupBlobs($blobs, $blobObj);
function backupBlobs($blobs, $blobObj) {
    foreach ($blobs as $blob) {
        if (strtotime($blob->lastmodified) >= DEFAULT_BACKUP_FROM_DATE && strtotime($blob->lastmodified) <= DEFAULT_BACKUP_TO_DATE) {
            $path = pathinfo($blob->name);
            if ($path['basename'] != '$$$.$$$') {
                $dir = $path['dirname'];
                $oldDir = getcwd();
                if (handleDirectory($dir)) {
                    chdir($dir);
                    $blobObj->getBlob(
                        AZURE_STORAGE_CONTAINER,
                        $blob->name,
                        $path['basename']
                    );
                    chdir($oldDir);
                }
            }
        }
    }
}
 
function handleDirectory($dir) {
    if (!checkDirExists($dir)) {
        return mkdir($dir, 0755, true);
    }
    return true;
}
 
function checkDirExists($dir) {
    if(file_exists($dir) && is_dir($dir)) {
        return true;
    }
    return false;
}
?>

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

Масштабируемость

Сайты Drupal в Windows Azure могут масштабироваться по мере увеличения нагрузки с помощью типичных стратегий масштабирования, масштабирования и кэширования. В следующих разделах описываются особенности реализации этих стратегий в Windows Azure.

Обычно вы принимаете решения о масштабируемости на основе мониторинга и планирования емкости. Мониторинг может быть выполнен в стадии подготовки во время тестирования или в производстве с нагрузкой в ​​реальном времени. Факторы планирования мощности в прогнозах для изменений в пользовательском спросе.

Увеличить масштаб

При настройке веб-роли перед развертыванием у вас есть возможность указать размер виртуальной машины (ВМ), например, Small или ExtraLarge . Каждый уровень размера добавляет дополнительную память, вычислительную мощность и пропускную способность сети для каждого экземпляра вашей веб-роли. Для экономии средств и меньших масштабных единиц вы можете протестировать свое приложение под ожидаемой нагрузкой, чтобы найти наименьший размер виртуальной машины, соответствующий вашим требованиям.

Рабочая нагрузка, обычно на большинстве популярных веб-сайтов Drupal, может быть разделена на ограниченный набор администраторов Drupal, которые вносят изменения в контент, и большую пользовательскую базу, которая выполняет в основном рабочую нагрузку только для чтения. Конечным пользователям может быть разрешено делать «записи», такие как загрузка блогов или публикация на форумах, но эти изменения не являются «изменениями содержания». Администраторы Drupal настроены на работу без кэширования, поэтому записи производятся непосредственно в SQL Azure или соответствующую базу данных. Эта рабочая нагрузка хорошо работает с размерами виртуальных машин Large или ExtraLarge . Кроме того, обратите внимание, что размер виртуальной машины тесно связан со всеми аппаратными ресурсами, поэтому, если существует много страниц с богатым содержимым, которые передают потоковое содержимое, требования к размеру виртуальной машины будут выше.

Чтобы внести изменения в параметр размера виртуальной машины, необходимо изменить атрибут vmsize элемента WebRole в файле определения службы ServiceDefinition.csdef. Изменение размера виртуальной машины требует повторного развертывания существующих приложений.

Уменьшить масштаб

В дополнение к размеру каждого экземпляра веб-роли вы можете увеличивать или уменьшать количество экземпляров, на которых работает сайт Drupal. Это распределяет веб-запросы по большему количеству серверов, что позволяет сайту обрабатывать больше пользователей. Чтобы изменить количество запущенных экземпляров вашей веб-роли, см. Раздел «Как масштабировать приложения путем увеличения или уменьшения количества экземпляров роли» .

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

Общий вопрос для любого решения Windows Azure заключается в том, существует ли какой-либо тип встроенного автоматического масштабирования. Windows Azure не предоставляет службы, которая обеспечивает автоматическое масштабирование. Однако можно создать специальное решение, которое масштабирует службы Azure с помощью API управления службами . Пример такого подхода см. В разделе « Модуль автоматического масштабирования для приложений PHP в Windows Azure» .

Кэширование

Кэширование является важной стратегией для масштабирования приложений Drupal в Windows Azure. Одна из причин этого заключается в том, что в SQL Azure реализованы механизмы регулирования для регулирования нагрузки на любую базу данных в облаке. Код, использующий SQL Azure, должен иметь надежную обработку ошибок и логику повторных попыток для учета этого. Дополнительные сведения см. В разделе « Сообщения об ошибках» (база данных SQL Azure) . Из-за возможности регулирования нагрузки, а также общего улучшения производительности настоятельно рекомендуется использовать кэширование.

Хотя Windows Azure предоставляет службу кэширования, в настоящее время эта служба не поддерживает взаимодействие с PHP. Поэтому лучшее решение для кэширования в Drupal — это использовать модуль, использующий технологию кэширования с открытым исходным кодом, например Memcached.

Вне определенного модуля Drupal вы также можете настроить Memcached для работы в PHP для Windows Azure. Дополнительную информацию смотрите в разделе Запуск Memcached в Windows Azure для PHP . Вот также пример того, как заставить Memcached работать в Windows Azure с помощью плагина: Windows Azure Memcached плагин .

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

Для простоты использования и экономии средств лучше всего работает размещение кэша между экземплярами веб-ролей сайта Drupal. Однако это предполагает, что на каждом экземпляре имеется доступная резервная память для применения к кешированию. Можно увеличить настройку размера виртуальной машины, чтобы увеличить объем доступной памяти на каждой машине. Также можно добавить дополнительные экземпляры веб-ролей для добавления в общую память кеша, одновременно улучшая способность веб-сайта реагировать на нагрузку. Можно создать выделенный кластер кеша в облаке, но шаги для этого выходят за рамки этой статьи[RR1].

Для хранилища BLOB-объектов Windows Azure также имеется функция кэширования, встроенная в службу, которая называется Сеть доставки контента (CDN). CDN обеспечивает высокоскоростной доступ к файлам в хранилище BLOB-объектов, кэшируя копии файлов в пограничных узлах по всему миру. Даже в пределах одного географического региона вы можете увидеть улучшения производительности, поскольку существует гораздо больше пограничных узлов, чем центров обработки данных Windows Azure. Дополнительные сведения см. В разделе « Доставка содержимого с высокой пропускной способностью с помощью Windows Azure CDN» .

Управляемость

Важно отметить, что каждая размещенная служба имеет промежуточную среду и рабочую среду. Это можно использовать для управления развертываниями, поскольку вы можете загрузить и протестировать и подготовить приложение к работе перед выполнением VIP-свопа с производством .

С точки зрения управляемости, Drupal имеет преимущество перед Windows Azure в том, как хранится содержимое сайта. Поскольку данные, необходимые для обслуживания страниц, хранятся в базе данных и хранилище больших двоичных объектов, нет необходимости повторно развертывать приложение для изменения содержимого сайта.

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

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