RabbitMQ生产部署指南

像RabbitMQ这样的数据服务通常有许多可调参数。一些配置对开发有很大的意义,但并不适合生产,本指南旨在为此提供帮助

虚拟主机

例如,在单租户环境中,当您的RabbitMQ集群专门为生产中的单个系统供电时,使用默认的虚拟主机(/)是完全正确的

在多租户环境中,为每个租户/环境使用单独的虚拟主机,例如project1_development, project1_production,project2_development和  project2_production等

用户

对于生产环境,请删除默认用户(guest),默认用户只能从本地主机默认连接,因为它具有众所周知的凭据。不要启用远程连接,而应考虑使用具有管理权限和生成密码的单独用户

建议每个应用程序使用一个单独的用户。例如,如果您有一个移动应用程序,一个Web应用程序和一个数据聚合系统,您将有3个独立的用户。这使得许多事情更容易:将客户端连接与应用程序关联

权限控制

认证和授权通常会混淆或互换使用。这是错误的,在RabbitMQ中,两者是分开的。为了简单起见,我们将认证定义为“标识用户是谁”,授权定义为“确定用户是什么,不允许做什么”

默认的虚拟主机和用户

  当服务器首次开始运行,并检测到其数据库未初始化或被删除时,它将使用一下资源初始化一个新的数据库

  一个名为 /虚拟主机

  一个名为guest的用户,默认密码为guest,被授予对/虚拟主机的完全访问权限

  明智的做法是删除guest用户或更改密码,特别是在公共网络上访问

  默认情况下guest用户被禁止远程连接到代理,它只能通过localhost连接。我们创建的其他用户默认情况下没有这种限制

  如果我们希望允许guest用户从远程主机连接,则应将loopback_users配置设置 为  none,如下:

loopback_users = none

权限如何工作

当一个RabbitMQ客户端建立到一个服务器的连接时,它指定了一个虚拟主机。此时执行第一级访问控制,服务器检查用户是否有权访问虚拟主机,否则拒绝连接尝试

资源(即交换和队列)在特定虚拟主机内被命名为实体;当对资源执行某些操作时,强制执行第二级访问控制

RabbitMQ在资源上有配置、写入、读取操作
                配置:创建或销毁资源,或更改其行为
                写: 写入消息到资源
                读: 检索资源的消息

内存

默认情况下,当RabbitMQ检测到使用的内存超过40%(由操作系统报告)时,将不会接收任何消息:{vm_memory_high_watermark,0.4},这是一个安全的默认值

在修改此值应该小心,即使主机是专用的RabbitMQ节点,因为如果没有足够的空闲系统内存,将会对操作系统交换造成不利影响,甚至会导致RabbitMQ进程终止

调整默认vm_memory_high_watermark时的一些建议

  托管RabbitMQ的节点应始终具有至少128MB的可用内存

  推荐的vm_memory_high_watermark范围是  0.40到0.66

  值不要超过0.7。操作系统和文件系统必须至少保留30%的内存,否则性能可能因寻呼而严重降级

比如修改配置调整为0.6,编辑rabbitmq.conf

vm_memory_high_watermark.relative = 0.6

磁盘空间

disk_free_limit默认值是50MB

  {disk_free_limit,{mem_relative,1.0}}是最小推荐值,和内存的容量一样大

  例如,在专用于具有4GB系统内存的RabbitMQ的主机上,如果可用磁盘空间低于4GB,所有发布者将被阻止,并且不会接收新消息。队列将需要被排空,通常由消费者,在发布之前将被允许恢复

  {disk_free_limit,{mem_relative,1.5}}是一个更安全的产品价值

  在具有4GB内存的RabbitMQ节点上,如果可用磁盘空间低于6GB,则所有新消息都将被阻止,直到磁盘警报清除

{disk_free_limit,{mem_relative,2.0}}是最保守的产品价值,我们想不出任何理由使用更高的产品。如果您希望RabbitMQ拥有所有需要的磁盘空间,编辑rabbitmq.conf,比如修改配置调整为2G

disk_free_limit.absolute = 2GB

打开文件句柄限制

保证您的环境至少允许有效的RabbitMQ用户使用至少50K的开放文件描述符,包括在开发环境中

监控

强烈建议监视系统的几个方面,从基础架构和内核度量到RabbitMQ到应用程序级度量。虽然监控需要在时间上进行前期投资,但在提前(或根本)解决问题方面非常有效。

参考zabbix监控(http://blog.thomasvandoren.com/monitoring-rabbitmq-queues-with-zabbix.html)

日志收集

强烈建议所有RabbitMQ节点和应用程序(如果可能的话)的日志都被收集和汇总。日志对于调查不寻常的系统行为至关重要

节点时间同步

节点时间同步

网络配置

TCP侦听器配置接口和端口

listeners.tcp.1 = 192.168.1.99:5672

将RabbitMQ配置为仅在IPv4和IPv6上的本地主机上侦听(双协议)

listeners.tcp.1 = 127.0.0.1:5672
listeners.tcp.2 = :: 1:5672

TCP缓冲区大小

这是关键的可调参数之一。每个TCP连接都有为其分配的缓冲区。一般来说,这些缓冲区越大,每个连接使用的内存就越多,吞吐量越好

在Linux系统上,操作系统默认会自动调整TCP缓冲区大小,通常在80-120KB之间

可以使用rabbit.tcp_listen_options, rabbitmq_mqtt.tcp_listen_options,  rabbitmq_amqp1_0.tcp_listen_options和相关的配置项来增加缓冲区大小

以下示例将AMQP 0-9-1连接的TCP缓冲区设置为192 KiB(请注意,将发送和接收缓冲区大小设置为不同的值是危险的,不推荐使用):即每个连接使用的RAM

tcp_listen_options.backlog = 128
tcp_listen_options.nodelay = true
tcp_listen_options.linger.on = true
tcp_listen_options.linger.timeout = 0
tcp_listen_options.sndbuf = 196608
tcp_listen_options.recbuf = 196608 

有些环境中每个节点持续并发连接数量比吞吐量更重要,因此需要为每个工作负载找到吞吐量和每个连接的RAM使用量之间的最佳值,不建议低于8K

连接握手超时

RabbitMQ的连接握手超时,默认10秒。当客户端运行在严重受限的环境中时,可能需要增加超时。这可以通过rabbit.handshake_timeout(毫秒)完成:

handshake_timeout = 20000

OS级调整

fs.file-MAX                     内核将分配的最大文件数量
net.ipv4.ip_local_port_range    本地IP端口范围,定义为一对值。范围必须为并发连接的峰值数量提供足够的条目
net.ipv4.tcp_tw_reuse           启用时,允许内核在TIME_WAIT 状态下重新使用套接字
net.ipv4.tcp_fin_timeout        将此值降低到5-10会减少关闭连接保持TIME_WAIT状态的时间。推荐用于预计大量并发连接的情况。
net.core.somaxconn              侦听队列的大小(同时建??立多少个连接)。默认值是128.增加到4096或更高,以支持入站连接突发,例如,当客户端重新连接时
net.ipv4.tcp_max_syn_backlog    记录的连接请求的最大数量尚未从连接客户端收到确认。默认值为128,最大值为65535.当优化吞吐量时,建议使用4096和8192开始值
net.ipv4.conf.default.rp_filter 启用反向路径过滤。如果IP地址欺骗 不是您的系统所关心的,请将其禁用

tcp_listen_options.nodelay      设置为true时,禁用 Nagle的算法。默认是真的。强烈建议大多数用户
tcp_listen_options.sndbuf       默认值由OS自动调整,通常在现代Linux版本的88 KiB至128 KiB范围内。增加缓冲区大小可提高每个连接的消费者吞吐量和RAM使用量。减少有相反的效果
tcp_listen_options.recbuf       默认值的效果与rabbit.tcp_listen_options.sndbuf类似,但是对于发布者和协议操作来说一般
tcp_listen_options.backlog      未接受的TCP连接队列的最大大小。达到这个尺寸时,新的连接将被拒绝。对于具有数千个并发连接和可能的批量客户端重新连接的环境,设置为4096或更高
tcp_listen_options.keepalive    当设置为true时,启用TCP保持活动(见上文)。默认是false。对于连接可以长时间闲置(至少10分钟)的环境有意义,但仍然建议使用心跳

TCP Keepalives
    net.ipv4.tcp_keepalive_time = 60
    net.ipv4.tcp_keepalive_intvl = 15
    net.ipv4.tcp_keepalive_probes = 4
    TCP包含一个类似于心跳(aka keepalive)的机制,在消息传递协议和上面的网络核对超时(TCP tickal timeout)中包含TCP保持活动。由于默认设置不足,TCP Keepalive通常不会按照预期的方式工作:需要很长时间(例如,一个小时或更长时间)才能检测到死亡的对等方。但是,通过调整,它们可以达到与心跳相同的目的,并且有意或无意地清除陈旧的TCP连接,例如选择不使用心跳的客户端。下面是TCP keepalive的sysctl配置示例,它认为TCP连接在120秒后死机或不可达(连接空闲60秒后每15秒4次尝试):
    在RabbitMQ操作员无法控制应用程序设置或使用的客户端库的环境中,TCP Keepalive可以成为有用的附加防御机制。

分区处理策略

在投入生产之前 选择分区处理策略非常重要
强烈建议不要在网络分区的环境中部署RabbitMQ集群

时间: 2024-10-24 21:40:44

RabbitMQ生产部署指南的相关文章

rabbitmq 生产环境配置

目录 一 rabbitmq 生产部署 1.1 rabbitmq.conf 1.2 advanced.config 1.3 rabbitmq-env.conf 1.4 在生产环境中不适用的策略. 一 rabbitmq 生产部署 RabbitMQ 常用的三种自定义服务器的通用方法: 配置文件 rabbitmq.conf 环境变量文件 rabbitmq-env.conf 补充配置文件 advanced.config rabbitmq.conf和rabbitmq-env.conf的位置 在二进制安装中路

Openstack 安装部署指南翻译系列 之 环境配置

1.1.1. 环境配置 为了最大限度地减少混乱并为OpenStack提供更多资源,建议最少安装Linux发行版.此外,必须在每个节点上安装64位版本的发行版. 环境选项主要包括以下几个部分: l 安全 l 主机网络 l 网络时间协议(NTP) l OpenStack包 l SQL数据库 l 消息队列 l Memcached 1.1.1.1. 安全 OpenStack服务支持各种安全方法,包括密码,策略和加密.另外,包括数据库服务器和消息代理在内的支持服务支持密码安全性. 为了简化安装过程,本指南

Openstack Mitaka for Centos7.2 部署指南(一)

本文主要参考 https://www.zybuluo.com/ncepuwanghui/note/389373 OpenStack Mitaka for Ubuntu 16.04 LTS 部署指南 http://docs.openstack.org/mitaka/install-guide-rdo/ 官方文档 把上面的Ubuntu 换成Centos,其他详情请看上面的部署指南 本文主要参考 https://www.zybuluo.com/ncepuwanghui/note/389373 Open

微软ASPNET站点部署指南(10):迁移至SQLServer(转载)

微软ASPNET站点部署指南(10):迁移至SQLServer 1.  综述 第2章的部署SQL Server Compact和第9章的部署数据库更新里解释了为什么最终要升级到完整版SQL Server .本章节将告诉你如何来做. SQL Server Express和完整版SQL Server 一旦你决定使用完整版SQL Server,你需要在开发和测试环境使用SQL Server Express 或者完整版SQL Server.在工具支持和数据库引擎功能上,SQL Server Compac

wamp2.4+composer+rabbitmq环境部署-176

version wamp 2.4 1.打开openssl 分别更改php.ini的文件配置 E:\wamp\bin\apache\Apache2.4.4\bin\php.ini E:\wamp\bin\apache\Apache2.4.4\bin\php.ini php.ini的功能打开 extension=php_openssl.dll 2.Composer下载 https://getcomposer.org/Composer-Setup.exe 下载完成直接点下一步图型安装-- 3.php-

nmon性能监控工具介绍与部署指南

1.nmon简要介绍 nmon是IBM开发,对操作系统层的性能监控工具,有aix和linux两种版本 2.nmon下载地址 2.1.nmon for aix下载地址 https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Power%20Systems/page/nmon 2.2 .nmonfor linux下载地址 http://nmon.sourceforge.net/pmwiki.php?n=Site.D

Redmine与Zentao同机快速部署指南

Redmine与Zentao 同机快速部署指南 1.环境 系统:CentOS 7 x64 软件:Redmine 3.0.Zentao 7.2 Source Redmine 3.0 是先安装的,目录 /opt/redmine,访问地址 http://127.0.0.1/redmine Zentao 7.2 是后安装的,目标访问地址 http://127.0.0.1/zentao 2.已知 Redmine与zentao 都依赖 apache mysql, apache 监听端口为 80 8080 s

tomcat集群机制剖析及其生产部署选型

为什么要使用集群? 为什么要使用集群?主要有两方面原因:一是对于一些核心系统要求长期不能中断服务,为了提供高可用性我们需要由多台机器组成的集群:另外一方面,随着访问量越来越大且业务逻辑越来越复杂,单台机器的处理能力已经不足以处理如此多且复杂的逻辑,于是需要增加若干台机器使整个服务处理能力得到提升. 集群难点在哪? 如果说一个web应用不涉及会话的话,那么做集群是相当简单的,因为节点都是无状态的,集群内各个节点无需互相通信,只需要将各个请求均匀分配到集群节点即可.但基本所有web应用都会使用会话机

cobbler自动化部署指南

文章结构 1. 前言 2. cobbler安装 3. 系统定制 4. 参考链接 前言: 给电脑装过系统的同学都知道,不论是从U盘.光驱或者其他设备装系统,都需要先在BIOS里设置开机启动项(或用开机快捷键设置).从上大学到现在,我帮同学装系统少说也有上百次,但是还从来没有使用从网卡启动安装过,虽然以前也注意到,但一直不知道那是个什么玩意,见图(1).前段时间在实习公司做Openstack的自动化安装与部署工作,才有幸接触到,原来这是一种从网卡远程启动的技术! 图1 BIOS启动项界面 要从网卡启