如何使用Azure WordPress实例通过Traffic Manager和CDN进行地理负载平衡

Tel*_*ler 5 mysql wordpress geolocation cleardb azure-traffic-manager

问题: 我在Azure上使用MySQL数据库的ClearDB安装了可扩展的WordPress实例(不是VM,而是Microsoft Azure的预配置WordPress Web应用程序实例)。我已经测试了Azure BLOB存储WordPress插件,它可以显示安装Azure存储的CDN中的数据。

我希望能够扩展我的WordPress实例以满足不同区域位置的需求。当前,我们的设置(不在Azure中,但使用4个由Ultima托管在不同地理数据中心中的VM)具有一个登台服务器(在美国)和3个在欧盟,非盟和美国的区域服务器。随着不同地区需求的增加(超过3个是可以的,如果我们可以深入到特定国家,那就太好了),我希望我的WordPress网站实例在该地区加速发展,并指导用户向最近的服务器发出请求他们的区域。

  • 如何使用流量管理器来定义区域,并告诉自服务器实例启动该区域中的另一个实例节点(而非VM)?

  • 如何确保该区域中的节点使用
    最接近该区域的ClearDB 副本(我不希望所有Web前端
    访问美国区域中单个位置的数据库)

  • 如何使用流量管理器确保从CDN(Azure存储)中提取的数据是从最接近
    请求区域的节点中提取的)?

  • 如何设置登台服务器并发布到公共节点,
    然后按区域特定位置扩大需求?

如果您阅读了我们目前如何进行全局WordPress故障转移设置,那么我的问题会更有意义。

当前的配置和背景故事 目前,我在全球的WordPress站点上分别在3个区域中托管的不同Ultima托管VM上进行了设置。

4台服务器

  • 舞台 -本地临时服务器VM接近我们在美国的办公室
  • 欧盟 -Ultima在欧盟地区托管的欧洲服务器。它是登台服务器的Hyper-V实例
  • AU-由Ultima在非盟地区托管的澳大利亚服务器。它是登台服务器的Hyper-V实例
  • 美国 -Ultima在美国地区托管的北美服务器。它是登台服务器的Hyper-V实例

WordPress:所有版本均安装了4.0.1版(不提供多版本)(我已编辑WordPress wp-config.php以根据请求的IP检测所请求的区域服务器(交换机/案例),然后为每个服务器设置配置文件以定义WordPress )。以下:

  • DB_NAME
  • DB_USER
  • DB_PASSWORD
  • DB_HOST
  • WP_HOME
  • WP_SITEURL

示例:对我们的欧盟服务器IE eu.contoso.com的请求将在与之匹配的CASE语句中具有以下值:

switch ($ip) {
  case (strstr ($ip, '255.255.255.255') == true):   // EU server request, set to port 3306
$port = '3306';
break;
}
$host =  $ip . ':' . $port;
SWITCH ($hostname) {
     case 'eu.contoso.com':  //This is the EU server
          define('DB_NAME', 'main_wp_website');
         /** MySQL database username */
        define('DB_USER', 'main_website_user');
        /** MySQL database password */
        define('DB_PASSWORD', 'main_website_password');
        /** MySQL hostname */
        define('DB_HOST', $host);
        define('WP_HOME', 'http://eu.contoso.net');
        define('WP_SITEURL', 'http://eu.contoso.net');
        break;
}
Run Code Online (Sandbox Code Playgroud)

原因:这允许用户从不同的请求点进入WordPress网站,并正确设置对该区域的数据库的数据库访问权限,并使用区域特定的根域重写URL。所有服务器的wp-config.php文件中都包含所有情况的所有配置文件,因此它们在服务器之间是相同的。

MySQL: 主服务器/从服务器复制中MySQL服务器设置的版本6(在每台服务器的my.ini中),从暂存到全局区域服务器

  • 登台 -设置为使用GTID进行复制的主服务器,以一种方式同步到全局区域服务器
  • 欧盟,澳大利亚,美国 -所有设置都以只读模式作为从属。他们接受登台服务器的复制更新,但无法发布回本地提交的数据

文件存储: 这是网站目录,WordPress内容目录(插件,主题,上传等)

  • 我们正在使用一种名为Syncovery的产品来监视这些文件夹并检测更改,并通过FTP自动将文件同步到其他服务器类似的文件夹

  • 当Syncovery花费太长时间无法检测到更改时,我们使用BeyondCompare进行手动同步

流量路由: 我们使用称为EdgeDirector的DNS服务,该服务从发出请求的IP中检测区域,并将发出请求的用户路由到距离其区域最近的服务器。

我要防止的事情 目前,我们的文件存在同步问题(数据库复制很好,没有问题)。我们的同步程序必须不断扫描和同步数十万个文件,并且当检测到文件更改时,将启动扫描(这需要时间),然后复制检测到的文件差异(根据文件大小,这也需要时间) )。如果在启动扫描后,另一个文件或文件夹发生更改,我们必须等待第一个扫描/文件副本完成。这导致将发布的内容从暂存服务器推送到公共集群的时间过长。

我也不想维护4个不同的实例/服务器。我最多希望我们有一个暂存实例和一个公共实例,并根据特定地区的需求进行扩展/缩小。

  • 暂存/公共实例设置在Azure中如何工作?
  • 如何同时配置登台实例和公共实例?我认为除了服务器名和数据库名外,它们将完全相同。
  • 我将如何执行从分期发布到公开发布的更改?

有没有更简单的方法可以使可伸缩的WordPress网站根据我上面描述的需求在全球不同地区可用? 我是天蓝色的初学者,我发现旧方法不一定是新云环境中最好的方法。

我对如何使WordPress网站在Azure上运行有一个好主意,并且已经使用ClearDB和Azure BLOB Storage拥有一个工作实例。我真的只是想知道如何像我们当前的设置那样在区域上进行扩展,或者通过确保用户始终访问最近的服务器来满足我们在不同区域区域中用户的需求的新方法,并在需要时自动对其进行配置和扩展出现。