负载均衡器背后的SilverStripe [英] SilverStripe behind load balancer

问题描述

我有一个SilverStripe实例在AWS负载均衡器后面的两台服务器上运行.要共享会话信息，我正在运行Elasticache Redis服务器.我正在这样设置我的php会话存储信息:

I've got an instance of SilverStripe running on two servers behind an AWS load balancer. To share the session information I'm running Elasticache Redis server. I'm setting my php session store info as such:

ini_set('session.save_handler', 'redis');
ini_set('session.save_path', 'tcp://127.0.0.1:6379');

登录到CMS的admin部分后，我可以在服务器之间跳转，它会记住我，但是在CMS中的各个部分之间切换时，主要部分不会呈现(AJAX调用).据我所知，另一台服务器没有意识到(无论您请求哪个服务器)，您都已经加载了CMS admin，并且在响应标头中说要加载新版本的JS依赖项，然后将admin忽略掉.无法加载.

After I've signed into the admin section of the CMS I can jump between servers and it remembers me, however when switching between sections in the CMS the main section doesn't render (an AJAX call). From what I can tell the other server doesn't realise (which ever one you request from second) you already have the CMS admin loaded and in the response headers says to load a new version of JS dependencies which then wigs out the admin and it doesn't load.

阅读文档 SilverStripe正在使用Zend_Cache进行某些操作额外的信息.我认为如果我加载管理界面，然后删除缓存目录，它将复制该问题.不是.

Reading into the docs SilverStripe is using Zend_Cache for some extra information. I figure if I load the admin interface, then delete the cache directory it would replicate the problem. It doesn't.

然后，我尝试使用此模块来更改Zend_Cache所在的存储引擎使用.我加了:

I then tried to use this module to change the storage engine that Zend_Cache is using. I added:

SS_Cache::add_backend(
    'primary_redis', 
    'Redis',
    array(
        'servers' => array(
            'host' => 'localhost', 
            'port' => 6379, 
            'persistent' => true, 
            'weight' => 1, 
            'timeout' => 5,
            'retry_interval' => 15, 
            'status' => true, 
            'failure_callback' => null
        )
    )
);
SS_Cache::pick_backend('primary_redis', 'any', 10);

对于我的mysite/_config.php来说，它在Redis中存储了一些cms信息，例如键CMSMain_SiteTreeHints9b258b19199db9f9ed8264009b6c351b，但这仍然不能解决在负载平衡环境中在服务器之间进行切换的问题.

To my mysite/_config.php and this is storing some cms information in redis like for the key CMSMain_SiteTreeHints9b258b19199db9f9ed8264009b6c351b, however this still doesn't fix the problem of changing between servers in the load balanced environment.

SilverStripe还能在哪里存储缓存数据?我是否正确实施了该模块?

Where else could SilverStripe be storing cache data? Have I implemented the module correctly?

推荐答案

默认的管理界面(假设您使用的是3.x)使用​​名为jquery.ondemand的javascript库-这将跟踪已包含的文件(是require.js之类的一种很古老的先驱-仅在没有AMD且具有CSS支持的情况下.

The default admin interface (assuming you're using 3.x) uses a javascript library called jquery.ondemand - this tracks files that have already been included (a rather ancient sort of precursor to the likes of 'require.js' - only without the AMD, and with CSS support).

为此，与CMS本身无关的可能性极小-考虑到Web本质上是无状态的，并且您用来保存状态的方法在服务器之间共享(数据库和会话数据).

To this end the likelihood of this having anything to do with the CMS itself is minimal - considering that the web by nature is stateless, and that the method you're using to save state is shared across your servers (both database and session data).

在HA群集中的各个实例之间共享的 not 是物理文件.造成这种情况的原因可能是(但不一定是)是提供给ondemand的URI末尾的mtime标记-最初旨在避免因主题更改(开发人员进行或自动完成)而导致浏览器缓存出现问题

What is not shared across individual instances in your HA cluster is physical files. The cause here is likely (but not definitely going) to be the mtime stamp on the end of the URIs supplied to ondemand - originally intended to avoid issues with browser caching in respect to theme alterations (developer made or otherwise automated).

毫无疑问，您检查的标头包括(总是，无论由HAProxy，nginx，ELB或任何其他端点选择)X-Include-CSS和X-Include-JS-其中一个示例看起来像:

The headers as you've no doubt inspected include (always, no matter the endpoint chosen by HAProxy, nginx, ELB, or whatever) X-Include-CSS and X-Include-JS - of which an example looks like:

X-Include-JS:/framework/thirdparty/jquery/jquery.js?m=1481487203,/framework/javascript/jquery-ondemand/jquery.ondemand.js?m=1481487186,/framework/admin/javascript/lib.js?m=1481487181 [...]

这是每个请求的内容，ondemand可以检查并查看其中已经包含的内容以及需要添加的内容.

This is on each request, to which ondemand can inspect and see what is already included, and what needs to be added.

(顺便说一下，这些标头的大小是导致nginx标头缓冲区问题导致在默认设置中导致502的原因.)

(Incidentally the size of these headers are what cause nginx header buffer issues causing 502 in a 'default' setup.)

如果要部署静态代码，则静态文件 在平衡实例之间应保持相同的mtime-但这需要检查.另一方面，生成的文件(例如，使用Requirements::combine_files)将需要在所有实例之间(重新)生成(与站点的所有/assets一样)同步，在这种情况下，mtime应该持续存在.尽管APC可能是一个因素，但Zend_cache在这里不太可能产生任何影响.当然，在任何情况下都要检查的第一件事是我的前提是否成立-例如通过diff工具从两个后端运行标头响应.

The static files should be keeping the same mtime between balanced instances if you are deploying static code - but this is something to check. Generated files on the other hand (such as with Requirements::combine_files) will need to be synced on (re)generation between all instances as with all /assets for your site, in which case the mtime should persist. Zend_cache is quite unlikely to have any affect here, although APC may be a factor. Of course the first thing to check in any case is whether or not my premise holds true - e.g. to run the header responses from both back-ends through a diff tool.

这篇关于负载均衡器背后的SilverStripe的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！