Galaxy 生信平台(二)：生产环境部署
原因
默认情况下的 Galaxy 会启用下面的服务：
使用 SQLite (无服务器数据库)，因此您无需为快速或基本开发运行/配置额外的数据库服务器。但是，虽然SQLite 支持并发访问(concurrent access)，但它不支持多个并发写入，这会降低系统吞吐量。
使用基于 Python 编写的内置 HTTP 服务器。此服务器执行的大部分工作可以移动到 nginx 或 Apache，这将提高性能。
在本地运行所有工具。如果将 Galaxy 迁移到群集(cluster)将大大增加其服务和计算的能力。
在单个进程中运行，这是 CPython 中的性能问题。
Galaxy 附带以上的默认配置，以确保在进行基本开发时可以实现最简单，最防错的配置。正如您很快就会看到的，目标是尽可能多地从 Galaxy 流程中删除工作，因为这样做会大大加快其剩余职责的执行速度。这是由于 Python 全局解释器锁(GIL)，详细说明可以参考 Galaxy 的高级配置部分文档。
基础
实现 Galaxy 可扩展性的基础就是， 我们需要一个干净的环境！ 以下许多说明是适用于任何生产应用程序的最佳实践。
创建一个名为 galaxy 的 非 ROOT 用户 。当您要授予或限制对数据的访问权限时，作为现有用户运行将导致问题。
从一个全新版本的 Galaxy 开始，不要尝试从以前使用过的版本中进行切换以用于开发。下载并安装在 galaxy 用户主目录中。
应该由 galaxy 用户运行 Galaxy 托管的一系列系统服务(如 Apache，邮件服务器，数据库服务器等)。发布的的
contrib/目录中提供了初始化脚本，OS X 启动定义和 Solaris SMF manifests。您还可以在run.sh中使用--daemon和--stop-daemon参数来手动启动和停止 Galaxy 的服务，但仍然需要分离进行操作。当作为守护进程运行时，服务器的输出日志将写入galaxy.log而不是终端，除非使用--log-file参数进行自定义说明。为 Galaxy 提供自己的数据库用户和数据库，以防止 Galaxy 的架构与数据库中的其他表冲突。此外，限制 Galaxy 的数据库用户，以便它只能访问自己的数据库。
确保 Galaxy 使用干净的 Python 解释器。
$PYTHONPATH或解释器的site-packages/目录中的冲突可能会导致其他的一些问题。对于 Galaxy 自身的框架依赖项 Galaxy 可以自行进行管理，因此您不必担心。最简单的方法是使用virtualenv：
nate@weyerbacher% pip install virtualenv
nate@weyerbacher% virtualenv --no-site-packages galaxy_env
nate@weyerbacher% . ./galaxy_env/bin/activate
nate@weyerbacher% cd galaxy-dist
nate@weyerbacher% sh run.sh
Galaxy 可以放在一个集群/网络文件系统中(它已经过 NFS 和 GPFS 测试)，如果你要在集群上运行它，可以参考：《Galaxy Admin Documentation: Connecting to a Cluster》。
基础配置
安装 Galaxy 的步骤大多遵循常规说明的步骤(regular instructions)。不同之处在于，在执行上述基础工作之后，您应该初始化配置文件( cp config/galaxy.yml.sample config/galaxy.yml )并在启动服务器之前按照下面的描述对其进行修改。如果在服务器运行时对此配置文件进行任何更改，则必须重新启动服务器才能使更改生效。
禁用开发人员设置
配置示例文件 config/galaxy.yml 中设置了两个选项，这些选项不应在生产服务器上启用。您应该将两者都设置为 false ：
debug:false禁用在内存中加载整个响应的中间件，以便在页面中显示调试信息。如果保持启用状态，代理服务器可能会超时等待响应，或者如果 Galaxy 进程正在为大文件提供服务，则可能会耗尽内存。use_interactive:false禁止通过 Web 显示和实时调试回溯。保持启用状态将暴露您的配置(数据库密码，id_secret 等)。禁用
filter-with:gzip。启用 gzip 过滤器将导致 UI 失败，因为一旦debug设置为False，模板就会流式传输。您仍然可以(并且鼓励)在代理服务器中启用gzip。
在部署期间，您可能会遇到失败作业的问题。默认情况下，Galaxy 会删除与作业执行相关的文件。您可以指示 Galaxy 保留失败作业的文件：cleanup_job:onsuccess
切换到数据库服务器
最重要的建议是切换到实际的数据库服务器。默认情况下，Galaxy 将使用 SQLite，它是一个无服务器的简单文件数据库引擎。由于它是无服务器的，因此所有数据库处理都在 Galaxy 进程中进行。这有两个缺点：它占用前面提到的 GIL(意味着该进程不能自由地执行其他任务)，并且它不如专用数据库服务器那么高效。还有其他缺点：当多个用户的负载增加时，事务锁的风险也会增加。锁定将导致(除其他外)超时和作业错误。如果从 SQLite 开始，然后意识到需要数据库服务器，则需要迁移数据库或重新开始。Galaxy 没有提供从 SQLite 迁移数据的内部方法，虽然 Web 上提供了免费的转换工具，但这个过程并非易事。
出于这个原因，Galaxy 还支持 PostgreSQL 和 MySQL。PostgreSQL 是首选，因为我们发现它在我们的数据库抽象层 SQLAlchemy 中运行得更好。
要使用外部数据库，您需要自行去安装和设置。该过程超出了本文档的范围，但通常很简单。例如，在 Debian 和基于 Redhat 的 Linux 发行版上，可能已经安装了一个。如果没有，它应该是 apt-get install 或 yum install 。在 macOS 上，PostgreSQL 网站上提供了安装程序。CentOS 下安装 PostgreSQL，请参考：《Linux 下 PostgreSQL 源码编译安装》。
安装后，创建一个新用户和该新用户所属的新数据库。无需进一步设置，因为 Galaxy 会管理自己的架构。如果您使用 UNIX 套接字(UNIX socket)将应用程序连接到数据库（这是标准情况，如果 Galaxy 和数据库在同一系统上），运行 Galaxy 进程时您将要为数据库用户命名为与您所在的系统用户相同的名称。
要配置 Galaxy，请在 Galaxy 的配置文件 config/galaxy.yml 中设置 database_connection 。数据库 URL 相关的语法在 SQLAlchemy documentation 中有详细的描述。
postgresql://username:password@localhost/mydatabase
mysql://username:password@localhost/mydatabase
postgresql:///mydatabase?host=/var/run/postgresql
mysql:///mydatabase?unix_socket=/var/run/mysqld/mysqld.sock
有关数据库 URL 可用选项的更多提示，参考：SQLAlchemy documentation。
如果您使用 MySQL 并遇到 "MySQL server has gone away" 的错误，请注意config/galaxy.yml主配置文件中的以下选项：
database_engine_option_pool_recycle
如果您使用的是 MySQL，请确保数据库输出为 UTF-8，否则您可能会遇到 Python TypeErrors。
如果您使用 MySQL 和 MyISAM 表引擎，当 Galaxy 处于多进程配置时，工作流程步骤可能出现无序执行 (get executed out of order) 并失败。请改用 InnoDB 引擎或切换到 PostgreSQL。
使用代理服务器
Galaxy 包含了一个独立的 Web 服务器，可以直接向客户端提供所有内容。但是，某些任务(例如提供静态内容)可以负载到更有效地处理这些任务的专用服务器。代理服务器还允许您使用代理支持的任何方法(例如，Kerberos 或 LDAP)在外部对用户进行身份验证，指示浏览器缓存内容以及压缩出站数据。此外，Galaxy 的内置 Web 服务器不支持字节范围请求(许多外部显示应用程序所需)，但可以将此功能负载到代理服务器。除了释放 GIL 之外，压缩和缓存还可以减少页面加载的时间。
下载和上载数据也可以移动到代理服务器。详细介绍可以参考：Make the proxy handle uploads and downloads。
Galaxy 官方提供了提供了基于 Apache 和 Nginx 以下的配置示例：
Nginx，高性能的反向代理，公共 Galaxy 网站目前在使用中。
Apache，具有成熟代理功能，且广泛部署的通用 Web 服务器。
使用计算集群
Galaxy 是一个运行命令行工具的框架，如果配置正确，可以在计算群集上运行这些工具。如果没有群集，您将受限于服务器中的核心数量，减去运行 Galaxy 本身所需的核心数量。Galaxy 目前支持 TORQUE PBS，PBS Pro，Platform LSF 和 Sun Grid Engine 集群，不需要专用或特殊的集群配置。只要在该平台上可以使用运行这些工具所需的依赖，Galaxy 的工具甚至可以在异构集群节点(不同的操作系统)上运行。
使用群集还可以为您带来附带好处：在本地运行工具时，它们是 Galaxy 服务器的子进程。这意味着如果重新启动服务器，则会失去与这些作业的联系，并且必须重新启动它们。但是在群集上，如果 Galaxy 服务器重新启动，作业将继续运行并完成。一旦 Galaxy 工作正常启动，它将恢复跟踪并完成工作，就好像什么也没发生过一样。
设置群集后，Galaxy 的配置并不困难。详细的集群相关配置信息，可以参考 Galaxy cluster page。
清理数据集
从历史记录或库中删除数据集时，只会将其标记为已删除但未实际删除，因为以后可以取消删除。为了释放磁盘空间，可以运行一组脚本(例如， cron/ 目录相关脚本)以删除本地策略指定的数据文件。有关说明，请参阅 “清除历史记录和数据集” 页面。
日志切换
要使用 logrotate 切换 Galaxy 日志文件，请将名为galaxy 的新文件添加到
/etc/logrotate.d/ 目录中，例如：
PATH_TO_GALAXY_LOG_FILES {
weekly
rotate 8
copytruncate
compress
missingok
notifempty
}
本地数据
要开始设置本地数据，请参考：Data Integration。
所有本地参考基因组必须包含在
builds.txt文件中。某些工具(例如，Extract Genomic DNA)要求您缓存(可能很大)本地 .2bit 格式数据。
其他工具(例如，Bowtie2)要求您缓存 .fasta 数据和特定工具的索引文件。
galaxy_dist/tool-data/目录包含一系列，用于描述元数据以及本地数据和索引路径的 location 示例(.loc)文件。从 Galaxy Tool Shed 中安装的工具包，也可能包含 location 文件。
location 文件中的注释，说明了该工具所需要的数据格式，设置前可以参考。
- Data Integration 文档解释了如何获取、创建或重新编写许多常见数据和索引。有关更多详细信息，请参见各个 Tool Shed 存储库的文档。
通过 FTP 启用上传
由于快速提升的测序技术，文件大小已经变得非常大，并且通过浏览器上传这些文件并不总是可行的。值得庆幸的是，一个简单的解决方案是允许 Galaxy 用户通过 FTP 上传它们并将这些文件导入其历史记录中。详细的的配置请参考 File Upload via FTP page 中的说明。
高级配置
负载平衡和 Web 应用程序扩展
如前所述，由于 Python 全局解释器锁(GIL，Global Interpreter Lock)，从 Galaxy 进程中 unloading work 非常重要。GIL 是 Python 确保线程安全的方式，它通过一次只允许一个线程控制执行来实现这一点。这意味着无论服务器中的核心数量如何，Galaxy 都只能使用一个核心。但是，有一个解决方案：运行多个 Galaxy 进程并使用代理服务器来平衡所有这些进程。实际上，Galaxy 分为作业处理程序和 Web 服务器进程。作业处理程序不直接通过 Web 为任何用户请求提供服务。相反，他们会在数据库中查看新作业，并在找到它们后，处理它们的准备，监视，运行和完成。同样，Web 服务器进程可以自由处理服务内容和文件到 Web 客户端。
有关如何配置扩展和负载平衡的完整详细信息，请参阅 the scaling 文档。
调整数据库
PostgreSQL 可以比 Galaxy 更有效地存储结果，从而减少 Galaxy 的内存占用。进行查询时，结果将保留在 Postgres 服务器上，Galaxy 可以只需要检索所需的行。要启用此功能，请在 Galaxy 配置中设置：database_engine_option_server_side_cursors:true 。
database_engine_option_pool_siz
database_engine_option_max_overflowdatabase_engine_option_strategy:threadlocal 。
使代理处理上传和下载
默认情况下，Galaxy 从代理服务器接收文件流上传，然后将此文件写入磁盘。同样，它将文件作为流发送到代理服务器。这占据了 Galaxy 流程中的 GIL，并且会降低该流程中其他操作的响应能力。要解决此问题，您可以将代理服务器配置为直接提供下载，仅涉及授权用户有权读取数据集的任务。如果使用 nginx 作为代理，您可以将其配置为接收上传的文件并将其写入磁盘本身，只有在完成后才通知 Galaxy。有关如何配置这些内容的所有详细信息都可以在 Apache 和 nginx 代理指令页面上找到。
总结
以上就是 Galaxy 生信平台基于生产环境下部署的一些建议，其中涉及了很多数据库、系统，以及服务器、集群相关的知识。从个人而言，这是一个极好的实战学习项目；从公司而言，也是从传统命令行生信分析向可视化界面处理的一个很好开源案例，值得借鉴与参考。
目前，关于 Galaxy Project 在国内的深入研究相关介绍与文档不是很多，如果您有任何的想法，欢迎留言交流。
往期精彩：
本文分享自微信公众号 - 生信科技爱好者（bioitee）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
