企业OpenVPN部署认证实战

开源技术欺壹世 发表了文章 • 0 个评论 • 100 次浏览 • 2017-01-04 17:57 • 来自相关话题

相关概念

1、vpn 介绍
vpn 虚拟专用网络,是依靠isp和其他的nsp,在公共网络中建立专用的数据通信网络的技术。在vpn中任意两点之间的链接并没有传统的专网所需的端到端的物理链路,而是利用公共网络资源动态组成的,可以理解为通过私有的隧道技术在公共数据网络上模拟出来的和专网有相同功能的点到点的专线技术,所谓虚拟是指不需要去拉实际的长途物理线路,而是借用公共的Internet网络实现。
 
2、vpn 作用
vpn可以帮助公司用的远程用户(出差,家里)公司的分之机构、商业合作伙伴及供应商等公司和自己的公司内部网络之间建立可信的安全连接或者局域网连接,确保数据的加密安全传输和业务访问,对于运维工程师来说,还可以连接不同的机房为局域网,处理相关的业务流。
 
3、常见vpn功能的开源产品
3.1 pptp vpn  
最大优势在于无需在windows客户端单独安装vpn客户端软件,windows默认就支持pptp vpn拨号功能。他是属于点对点的方式应用,比较适合远程企业用户拨号到企业进行办公等应用,缺点很多小区及网络设备不支持pptp导致无法访问。
 
3.2 SSL VPN(openvpn)
PPTP主要为常在外面移动或者家庭办公的用户考虑的,而OpenVpn不但可以使用与PPTP的场景,还是和针对企业异地两地总分公司之间的vpn不间断按需链接,例如:ERP,OA及时通讯工具等在总分公司企业中的应用,缺点:需要单独安装客户端软件。
 
3.3 IPSEC VPN 
 IPSEC VPN 也适合针对企业异地两地中分公司或者多个IDC机房之间的VPN的不间断按需链接,并且在部署使用上更简单方便。IPSEC Vpn的开源产品openswan.
 
4、openvpn通讯原理
openvpn所有的通讯都基于一个单一的ip端口(默认1194),默认使用udp协议,同时也支持tcp。openvpn能通过大多数的代理服务器,并且能在NAT的环境很好的工作。openvpn服务端具有客户端“推送”某些网络配置信息的功能,这些信息包括,ip地址,路由设置等。 OPenvpn提供了2个虚拟网络接口:通过TUN/Tap驱动,通过他们,可以建立三层IP隧道,或者虚拟二层以太网,后者可以传送任何类型的二层以太网数据。传送的数据可通过LZO算法压缩。openvpn2.0以后版本每个进程可以同时管理数个并发的隧道。
 
5、openvpn协议选择
在选择协议的时候,需要注意2个加密隧道支架你的网络状况,如果高延迟或者丢包较多的情况下,请选择TCP协议作为底层协议,UDP协议由于存在无连接和重传机制,导致隧道上层的协议进行重传,效率非常低下,这里建议用tcp协议方式。
 
6、openvpn的依赖及核心技术
openvpn依赖Openssl,可以使用预设的私钥,第三方证书,用户名密码等进行身份验证。openvpn的技术核心是虚拟网卡,其次是SSL协议实现。
 

服务器端安装部署

相关软件:lzo压缩模块,可加快传输速度,openvpn 主程序。
 
安装环境:centos6.4 x64 下安装
1、安装lzo
# cd /usr/local/src/
# wget http://www.oberhumer.com/opensource/lzo/download/lzo-2.03.tar.gz
# tar zxf lzo-2.06.tar.gz
# cd lzo-2.06
# ./configure
# make
# make install2、安装openvpn
# yum install -y openssl* -y && cd /usr/local/src/
# wget http://www.openvpn.net/release/openvpn-2.2.2.tar.gz
# tar zxf openvpn-2.2.2.tar.gz
# cd openvpn-2.2.2
# ./configure --with-lzo-headers=/usr/local/include --with-lzo-lib=/usr/local/lib
# make
# make install
安装环境:ubuntu 12.04 x64 下安装
1、主程序安装
# aptitude install openvpn
# aptitude install libpam-dev libpam-mysql libmysql++-dev sasl2-bin2、检查安装
# ls /usr/share/doc/|grep openvpn
openvpn ##发现已经存在。3、生成证书
#cd /usr/share/doc/openvpn/examples/easy-rsa/2.0/
# . ./vars ##### 重成环境变量 以下生成的文件都在/usr/share/doc/openvpn/examples/easy-rsa/2.0/keys 下
# ./clean-all ###用来清除之前生成的所有的key
# ./build-ca ####生成ca.crt ca.key4、建立给server用的certificate & key
#./build-key-server server
##“Common Name” 设成 “server”
##会产生以下文件
01.pem
server.crt
server.csr
server.key5、建立给client用的certificate & key(可以建立多个client)## “Common Name” 设成 “clinet1” 以此类推
# ./build-key client1
##生成
client1.crt
client1.csr
client1.key
# ./build-key client2
# ./build-key client3
##当然,你也可以只生成一个client,我就是这样做的6、建立 Diffie Hellman parameters 和 ta.key# ./build-dh #建立 Diffie Hellman parameters 会生成dh{n}.pem。
# openvpn --genkey --secret ta.key #生成ta.key,防止ddos攻击,client和server同时存储7、拷贝相关文件至/etc/openvpn下。# mv keys/* /etc/openvpn/
# mv ta.key /etc/openvpn/ #不要遗漏8、建立配置文件/etc/openvpn/server.conflocal 10.0.9.10 ###本机IP,这是一个内网IP,不过在路由上已经做了IP 的映射到一个外网ip
port 1194##指定端口
proto tcp #制定协议
dev tun
;tls-server
ca ca.crt
cert server.crt
key server.key
tls-auth ta.key 0
dh dh1024.pem
server 10.8.0.0 255.255.255.0#拨入后的ip段及网关
ifconfig-pool-persist ipp.txt
#push “redirect-gateway” # 自動將 client 的 default gateway 設成經由 VPN server 出去
keepalive 10 120 # 保持連線,每 10 秒 ping 一次,若是 120 秒未收到封包,即認定 client 斷線
comp-lzo #启用压缩
max-clients 20 # 最多同時只能有十個 client
user nobody
group nogroup # vpn daemon 執行時的身份(在非 Windows 平台中使用)
persist-key #当vpn超时后,当重新启动vpn后,保持上一次使用的私钥,而不重新读取私钥。
persist-tun #通过keepalive检测vpn超时后,当重新启动vpn后,保持tun或者tap设备自动链接状态。
status /etc/openvpn/easy-rsa/keys/openvpn-status.log #日志状态信息
log /var/log/openvpn.log #日志文件
verb 3 ## 日志文件冗余。
# 以下二行是將 vpn server 內部的虛擬 ip 機器開放給 client 使用
push "route 10.0.1.0 255.255.255.0"
push "route 10.0.2.0 255.255.255.0"
push "route 10.0.3.0 255.255.255.0"
plugin ./openvpn-auth-pam.so /usr/sbin/openvpn ###这个是用来mysql 认证的,如不需要可注释掉9、开启操作系统的IP转发设置。# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE10、建立mysql认证文件。# vi /etc/pam.d/openvpn
auth sufficient pam_mysql.so user=vpn passwd=vpnjkb host=127.0.0.1:3306 db=vpn \
table=vpnuser usercolumn=name passwdcolumn=password \
where=active=1 sqllog=0 crypt=2 verbose=1
account required pam_mysql.so user=vpn passwd=vpnjkb host=127.0.0.1:3306 db=vpn \
table=vpnuser usercolumn=name passwdcolumn=password \
where=active=1 sqllog=0 crypt=2 verbose=111、创建vpn库、授权、建表mysql> create database vpn;##创建数据库vpn。
mysql> GRANT ALL ON vpn.* TO vpn@localhost IDENTIFIED BY ‘vpnjkb‘;##授权localhost上的用户vpn(密码vpn123)有对数据库vpn的所有操作权限。
mysql> flush privileges;##更新sql数据库的权限设置。
mysql> use vpn;##使用刚创建的的vpn数据库。
mysql> CREATE TABLE vpnuser (
-> name char(20) NOT NULL,
-> password char(128) default NULL,
-> active int(10) NOT NULL DEFAULT 1,
-> PRIMARY KEY (name)
-> );
mysql> insert into vpnuser (name,password) values(’soai’,password(’soai’));
##命令解释:
#创建vpn用户,对vpn这个database有所有操作权限,密码为vpn123
#active不为1,无权使用VPN12、拷贝文件# cp /usr/lib/openvpn/openvpn-auth-pam.so /etc/openvpn/13、可选配置#client-cert-not-required #不请求客户的CA证书,使用User/Pass验证
#username-as-common-name #使用客户提供的UserName作为Common Name
#client-to-client #如果让Client之间可以相互看见,去掉本行的注释掉,否则Client之间无法相互访问
#duplicate-cn #是否允许一个User同时登录多次,去掉本行注释后可以使用同一个用户名登录多次14、下载相关文件给客户端用##下载下列文件
client.crt clinet.key ca.crt ta.key
 
 

客户端配置

1、客户端下载地址:
http://swupdate.openvpn.org/community/releases/openvpn-2.2.2-install.exe   ##windows

http://swupdate.openvpn.org/community/releases/openvpn-2.2.2.tar.gz    ##linux or mac
 
2、创建client.ovpn文件client
dev tun
proto tcp
remote 8.8.8.8 1194 #公网ip 和 端口
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
tls-auth ta.key 1
;comp-lzo
verb 3
auth-user-pass3、把client.ovpn加上之前client.crt  clinet.key ca.crt    ta.key 放入一个config文件夹,并移动至vpn安装的主目录

4、启动客户端,输入用户名密码即可。#用户名密码在服务器端,mysql中添加的用户密码。
 

其他

1、关于auto认证相关可参考:http://b.gkp.cc/2010/08/08/setup-openvpn-with-mysql-auth/  
 
2、后期维护
a、如果后期重新添加key的话
source vars
./build-keyb、后期客户端的吊销source vars
./revoke-full xiaowang #-->会生成crl.pem文件检查keys/index.txt,发现被吊销的用户前面有个R

怎么使吊销的生效呢,就是在server.conf里面加上 #crl-verify /etc/openvpn/keys/crl.pem,然后重启openvpn服务生效。 查看全部
openvpn.png


相关概念


1、vpn 介绍
vpn 虚拟专用网络,是依靠isp和其他的nsp,在公共网络中建立专用的数据通信网络的技术。在vpn中任意两点之间的链接并没有传统的专网所需的端到端的物理链路,而是利用公共网络资源动态组成的,可以理解为通过私有的隧道技术在公共数据网络上模拟出来的和专网有相同功能的点到点的专线技术,所谓虚拟是指不需要去拉实际的长途物理线路,而是借用公共的Internet网络实现。
 
2、vpn 作用
vpn可以帮助公司用的远程用户(出差,家里)公司的分之机构、商业合作伙伴及供应商等公司和自己的公司内部网络之间建立可信的安全连接或者局域网连接,确保数据的加密安全传输和业务访问,对于运维工程师来说,还可以连接不同的机房为局域网,处理相关的业务流。
 
3、常见vpn功能的开源产品
3.1 pptp vpn  
最大优势在于无需在windows客户端单独安装vpn客户端软件,windows默认就支持pptp vpn拨号功能。他是属于点对点的方式应用,比较适合远程企业用户拨号到企业进行办公等应用,缺点很多小区及网络设备不支持pptp导致无法访问。
 
3.2 SSL VPN(openvpn)
PPTP主要为常在外面移动或者家庭办公的用户考虑的,而OpenVpn不但可以使用与PPTP的场景,还是和针对企业异地两地总分公司之间的vpn不间断按需链接,例如:ERP,OA及时通讯工具等在总分公司企业中的应用,缺点:需要单独安装客户端软件。
 
3.3 IPSEC VPN 
 IPSEC VPN 也适合针对企业异地两地中分公司或者多个IDC机房之间的VPN的不间断按需链接,并且在部署使用上更简单方便。IPSEC Vpn的开源产品openswan.
 
4、openvpn通讯原理
openvpn所有的通讯都基于一个单一的ip端口(默认1194),默认使用udp协议,同时也支持tcp。openvpn能通过大多数的代理服务器,并且能在NAT的环境很好的工作。openvpn服务端具有客户端“推送”某些网络配置信息的功能,这些信息包括,ip地址,路由设置等。 OPenvpn提供了2个虚拟网络接口:通过TUN/Tap驱动,通过他们,可以建立三层IP隧道,或者虚拟二层以太网,后者可以传送任何类型的二层以太网数据。传送的数据可通过LZO算法压缩。openvpn2.0以后版本每个进程可以同时管理数个并发的隧道。
 
5、openvpn协议选择
在选择协议的时候,需要注意2个加密隧道支架你的网络状况,如果高延迟或者丢包较多的情况下,请选择TCP协议作为底层协议,UDP协议由于存在无连接和重传机制,导致隧道上层的协议进行重传,效率非常低下,这里建议用tcp协议方式。
 
6、openvpn的依赖及核心技术
openvpn依赖Openssl,可以使用预设的私钥,第三方证书,用户名密码等进行身份验证。openvpn的技术核心是虚拟网卡,其次是SSL协议实现。
 


服务器端安装部署


相关软件:lzo压缩模块,可加快传输速度,openvpn 主程序。
 
安装环境:centos6.4 x64 下安装
1、安装lzo
# cd /usr/local/src/
# wget http://www.oberhumer.com/opensource/lzo/download/lzo-2.03.tar.gz
# tar zxf lzo-2.06.tar.gz
# cd lzo-2.06
# ./configure
# make
# make install
2、安装openvpn
# yum install -y openssl* -y  && cd /usr/local/src/
# wget http://www.openvpn.net/release/openvpn-2.2.2.tar.gz
# tar zxf openvpn-2.2.2.tar.gz
# cd openvpn-2.2.2
# ./configure --with-lzo-headers=/usr/local/include --with-lzo-lib=/usr/local/lib
# make
# make install

安装环境:ubuntu 12.04 x64 下安装
1、主程序安装
# aptitude install openvpn
# aptitude install libpam-dev libpam-mysql libmysql++-dev sasl2-bin
2、检查安装
# ls /usr/share/doc/|grep openvpn
openvpn ##发现已经存在。
3、生成证书
#cd  /usr/share/doc/openvpn/examples/easy-rsa/2.0/ 
# . ./vars ##### 重成环境变量 以下生成的文件都在/usr/share/doc/openvpn/examples/easy-rsa/2.0/keys 下
# ./clean-all ###用来清除之前生成的所有的key
# ./build-ca ####生成ca.crt ca.key
4、建立给server用的certificate & key
#./build-key-server server 
##“Common Name” 设成 “server”
##会产生以下文件
01.pem
server.crt
server.csr
server.key
5、建立给client用的certificate & key(可以建立多个client)
## “Common Name” 设成 “clinet1” 以此类推
# ./build-key client1
##生成
client1.crt
client1.csr
client1.key
# ./build-key client2
# ./build-key client3
##当然,你也可以只生成一个client,我就是这样做的
6、建立 Diffie Hellman parameters 和 ta.key
#  ./build-dh #建立 Diffie Hellman parameters 会生成dh{n}.pem。
# openvpn --genkey --secret ta.key #生成ta.key,防止ddos攻击,client和server同时存储
7、拷贝相关文件至/etc/openvpn下。
# mv keys/* /etc/openvpn/
# mv ta.key /etc/openvpn/ #不要遗漏
8、建立配置文件/etc/openvpn/server.conf
local 10.0.9.10 ###本机IP,这是一个内网IP,不过在路由上已经做了IP 的映射到一个外网ip
port 1194##指定端口
proto tcp #制定协议
dev tun
;tls-server
ca ca.crt
cert server.crt
key server.key
tls-auth ta.key 0
dh dh1024.pem
server 10.8.0.0 255.255.255.0#拨入后的ip段及网关
ifconfig-pool-persist ipp.txt
#push “redirect-gateway” # 自動將 client 的 default gateway 設成經由 VPN server 出去
keepalive 10 120 # 保持連線,每 10 秒 ping 一次,若是 120 秒未收到封包,即認定 client 斷線
comp-lzo #启用压缩
max-clients 20 # 最多同時只能有十個 client
user nobody
group nogroup # vpn daemon 執行時的身份(在非 Windows 平台中使用)
persist-key #当vpn超时后,当重新启动vpn后,保持上一次使用的私钥,而不重新读取私钥。
persist-tun #通过keepalive检测vpn超时后,当重新启动vpn后,保持tun或者tap设备自动链接状态。
status /etc/openvpn/easy-rsa/keys/openvpn-status.log #日志状态信息
log /var/log/openvpn.log #日志文件
verb 3 ## 日志文件冗余。
# 以下二行是將 vpn server 內部的虛擬 ip 機器開放給 client 使用
push "route 10.0.1.0 255.255.255.0"
push "route 10.0.2.0 255.255.255.0"
push "route 10.0.3.0 255.255.255.0"
plugin ./openvpn-auth-pam.so /usr/sbin/openvpn ###这个是用来mysql 认证的,如不需要可注释掉
9、开启操作系统的IP转发设置。
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
10、建立mysql认证文件。
# vi /etc/pam.d/openvpn
auth sufficient pam_mysql.so user=vpn passwd=vpnjkb host=127.0.0.1:3306 db=vpn \
table=vpnuser usercolumn=name passwdcolumn=password \
where=active=1 sqllog=0 crypt=2 verbose=1
account required pam_mysql.so user=vpn passwd=vpnjkb host=127.0.0.1:3306 db=vpn \
table=vpnuser usercolumn=name passwdcolumn=password \
where=active=1 sqllog=0 crypt=2 verbose=1
11、创建vpn库、授权、建表
mysql> create database vpn;##创建数据库vpn。
mysql> GRANT ALL ON vpn.* TO vpn@localhost IDENTIFIED BY ‘vpnjkb‘;##授权localhost上的用户vpn(密码vpn123)有对数据库vpn的所有操作权限。
mysql> flush privileges;##更新sql数据库的权限设置。
mysql> use vpn;##使用刚创建的的vpn数据库。
mysql> CREATE TABLE vpnuser (
-> name char(20) NOT NULL,
-> password char(128) default NULL,
-> active int(10) NOT NULL DEFAULT 1,
-> PRIMARY KEY (name)
-> );
mysql> insert into vpnuser (name,password) values(’soai’,password(’soai’));
##命令解释:
#创建vpn用户,对vpn这个database有所有操作权限,密码为vpn123
#active不为1,无权使用VPN
12、拷贝文件
# cp /usr/lib/openvpn/openvpn-auth-pam.so /etc/openvpn/
13、可选配置
#client-cert-not-required #不请求客户的CA证书,使用User/Pass验证
#username-as-common-name #使用客户提供的UserName作为Common Name
#client-to-client #如果让Client之间可以相互看见,去掉本行的注释掉,否则Client之间无法相互访问
#duplicate-cn #是否允许一个User同时登录多次,去掉本行注释后可以使用同一个用户名登录多次
14、下载相关文件给客户端用
##下载下列文件
client.crt clinet.key ca.crt ta.key

 
 


客户端配置


1、客户端下载地址:
http://swupdate.openvpn.org/community/releases/openvpn-2.2.2-install.exe   ##windows

http://swupdate.openvpn.org/community/releases/openvpn-2.2.2.tar.gz    ##linux or mac
 
2、创建client.ovpn文件
client
dev tun
proto tcp
remote 8.8.8.8 1194 #公网ip 和 端口
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
tls-auth ta.key 1
;comp-lzo
verb 3
auth-user-pass
3、把client.ovpn加上之前client.crt  clinet.key ca.crt    ta.key 放入一个config文件夹,并移动至vpn安装的主目录

4、启动客户端,输入用户名密码即可。#用户名密码在服务器端,mysql中添加的用户密码。
 


其他


1、关于auto认证相关可参考:http://b.gkp.cc/2010/08/08/setup-openvpn-with-mysql-auth/  
 
2、后期维护
a、如果后期重新添加key的话
source vars
./build-key
b、后期客户端的吊销
source vars
./revoke-full xiaowang #-->会生成crl.pem文件
检查keys/index.txt,发现被吊销的用户前面有个R

怎么使吊销的生效呢,就是在server.conf里面加上 #crl-verify /etc/openvpn/keys/crl.pem,然后重启openvpn服务生效。

MYSQL的八大缺陷

数据库小白菜 发表了文章 • 0 个评论 • 119 次浏览 • 2016-12-29 11:39 • 来自相关话题

MySQL体积小,速度快,功能丰富,总体拥有成本低。它还是一个开源的关联式数据库管理系统,它的伟大成就说明了一个成功的公司是可以建立在开源之上的。
 
虽然用过mysql的人都曾对其出现的问题而抓狂,但只要是机器,总避免不了出问题的,更何况是一种每秒能保存成千上万行互联网数据,你怎么保证它一点错误都没有呢?
 
以下列举了8个开源关系型数据库的缺陷,其中不仅限于MySQL,还有是针对关系型数据库的。只有明白了关系型数据库和MySQL,才能更好地避免在使用MySQL中尽量少地遇到一些意外。
 

1、无法避免的bugs

任何一个软件包都有bug。但稍微深入了解一下,就会发现和Mysql相关的bugs自成体系。突然你就需要留心,因为NULL并不是以同样的方式出现,外键约束也没有像你想像的那样执行,连主键自动增长也会出错。

到处都避免不了小问题,而且并不总是可以修复的,这就是为什么一些人保持一个列表。还好MySQL维护着一个非常好的bug报告系统,让我们可以知道我些我们无法想像的事情,知道其他人也在经受同样的磨难。
 

2、关系表的不灵活性

关系表具有条理性是好的,但这迫使程序员要编造或把一些数据塞到已经定义好模式的列中。NoSQL之所以越来越受欢迎,其中一个原因就是它为程序员提供了足够的灵活性,以加速数据库的使用。如果一个街道地址需要增加一行,那么,你可以将它很容易地插入到一个NoSQL文档中。如果你想添加一个完整的新的数据块,无论它包含什么内容,文档模型也可以原封不动地接受你的数据,而不必改为它要求的数据格式。

假设你用整数格式建立了一个全部是邮编的表格。这个表十分高效,执行规则也很好。可是有一次,有人上传了一个使用了连字符的九位数邮编。或者说你得到了一位来自他国的客户的信件,上面写有邮政编码。这时,你会感到一切都乱了。老板要求网站要在几小时内恢复正常工作。然而,你已经没有时间重建数据库。程序员可以做什么?使用黑客手段把这位客户的邮政编码由base 64的数字格式改为base 10格式?或者设置一个使用转义编码的辅助表格,用来说明真正的邮政编码或者其他?危险的黑客无处不在,但你没有时间来搞定它。

MySQL的关联规则让每个人都诚实和谨慎,但它能强制我们避开易受攻击和欺骗的麻烦。
 

3、存储引擎混乱

总体来说,Mysql的存储引擎接口定义还算良好的。MySQL不是实际上的同一的数据库。它是由几个数据库组成,它们的大多数细节都被统一的表面掩盖了。开始时有一个MyISAM引擎,它很快但在前后一致上不能做到完备。有时你需要速度并且可以接受不一致的结果时是很好的。

当人们需要更多时,具备完整事务支持的Inno DB出现了。但这还不够。现在,它可能有20种存储引擎的选择——这足以使一个数据库管理员疯狂。当然,有时在不同的存储引擎之间切换而不必重写你的SQL是很好的,但是切换后总会带来混乱。这个表格我选择的引擎是MyISAM还是innoDB呢?或者,我决定输出的数据是CSV格式的吗?
 

4、JOIN联合查询

曾经,将数据分表保存是计算机科学史上的伟大创新。分开后的表不仅结构简单,使用上也简化了许多。但它却需要使用join语句来进行查询。

sql通过一系列join构建的复杂查询将开发者推入了困惑与绝望的深渊。而且存储引擎也需要以最优的方式来高效地解析join语句。开发者需要绞尽脑汁编写查询语句,然后数据库对其进行解析。

这就是很多注重运行速度的开发者放弃数据分表转而使用不规范数据表的原因。不区分数据实体,将所有数据保存到一个大表中——以避免复杂的查询。这样确实很快,并且服务器也不会耗尽内存。

现在的磁盘空间很廉价。8TB的磁盘已经在售,更大容量的也将上市。我们不再需要为使用join而绞尽脑汁了。
 

5、分支的混乱

毋庸置疑,一个可靠的、得到良好支持的MySQL分支,可以带来竞争和选择,但是它也引起困惑和混乱。更糟糕的是,一个称为MariaDB的MySQL分支,由Monty Widenius维护着。他同样也在参与编写MySQL。那么,Maria DB是真正独立的值得我们拥护的吗?或者它是MySQL?我们是否应该坚持使用由创建原始mysql数据库的组织运营的核心代码?或者我们应该加入那些被认为更聪明的,往往很酷的背叛者?

如何获取关于兼容性的信息?虽然Maria DB和MySQL十分相似,但它们之间也有差异。这就是大家一直都在争论它的原因。在性能方面,在我们查询的范围内,在两个阵营中,也许它们的工作方式相同,但也许不同,也许将来会不同。
 

6、开发MySQL的动机

虽然MySQL是一款成功的开源产品,但它仍属于商业中的一款产品,专业开发者需要靠它来获得利益,当然,最直接的利益就是薪资。当大多数用户在持续地享受开源许可证带来的最佳体验时,毫无疑问这家公司还在为赚取足够的钱来维持运营而努力。这导致自由代码在“社区版”和出售给企业的完整产品之间产生了奇怪的分岐。

我们应该对这款产品付钱吗?这种在社区版开展经营的行为是否公平?企业版中额外的功能是不是一个噱头,以引诱我们不断付费的呢?这至少说明一点,它是另一些需要回答的问题:选用哪个版本?遵照哪种许可证?选用它的哪个功能集?
 

7、原生JSON支持的缺乏

通过安装MySQL查看其年龄,然后你就知道需要添加哪些驱动程序使它变得可用。MySQL通常在3306端口上通信,一般输出的是它本身难以理解的格式化数据。如果要让你的代码和它通信,你必须添加另一层代码,将MySQL的语言转换成有用的东西。这些层的代码,以库的形式分发,经常需要人们购买一个商业许可证。

现代数据存储层通常直接以JSON通信。虽然MySQL和Maria DB现在有能力解析SQL中的JSON部分,但这还远远不够,原生的JSON接口已经被广泛使用于CouchDB、MongoDB,或任何最新的工具中。
 

8、封闭源和专有模块的兴起

虽然MySQL是开源的,但除了一些在”开源核心“周边开发的一些较新的、非开源的代码和专有模块。程序员也需要赚钱、需要生活,Oracle需要拿它的辛苦成果来换钱,这是一种现实,也是商业的性质。使用MySQL你也不可以免费得到任何东西。

要求MySQL始终坚持在一个很高的标准上,这有点不公平,因为开源的成功可能是一个圈套。它开始可以免费,但并不意味着它可以始终免费。如果企业需要更多新的功能,他们就要通过各种方式付费来获取。有时向Oracle付费,比自己来编写代码要便宜得多。有时商业的、不开源的代码是有意义的。

MySQL虽然作为一个成功的开源系统,但以上这些问题也总不可避免地出现,这就需要我们在它们发生之前有个深刻的认识,才能在今后的应用中避免不必要的麻烦。 查看全部
MYSQL.png

MySQL体积小,速度快,功能丰富,总体拥有成本低。它还是一个开源的关联式数据库管理系统,它的伟大成就说明了一个成功的公司是可以建立在开源之上的。
 
虽然用过mysql的人都曾对其出现的问题而抓狂,但只要是机器,总避免不了出问题的,更何况是一种每秒能保存成千上万行互联网数据,你怎么保证它一点错误都没有呢?
 
以下列举了8个开源关系型数据库的缺陷,其中不仅限于MySQL,还有是针对关系型数据库的。只有明白了关系型数据库和MySQL,才能更好地避免在使用MySQL中尽量少地遇到一些意外。
 


1、无法避免的bugs


任何一个软件包都有bug。但稍微深入了解一下,就会发现和Mysql相关的bugs自成体系。突然你就需要留心,因为NULL并不是以同样的方式出现,外键约束也没有像你想像的那样执行,连主键自动增长也会出错。

到处都避免不了小问题,而且并不总是可以修复的,这就是为什么一些人保持一个列表。还好MySQL维护着一个非常好的bug报告系统,让我们可以知道我些我们无法想像的事情,知道其他人也在经受同样的磨难。
 


2、关系表的不灵活性


关系表具有条理性是好的,但这迫使程序员要编造或把一些数据塞到已经定义好模式的列中。NoSQL之所以越来越受欢迎,其中一个原因就是它为程序员提供了足够的灵活性,以加速数据库的使用。如果一个街道地址需要增加一行,那么,你可以将它很容易地插入到一个NoSQL文档中。如果你想添加一个完整的新的数据块,无论它包含什么内容,文档模型也可以原封不动地接受你的数据,而不必改为它要求的数据格式。

假设你用整数格式建立了一个全部是邮编的表格。这个表十分高效,执行规则也很好。可是有一次,有人上传了一个使用了连字符的九位数邮编。或者说你得到了一位来自他国的客户的信件,上面写有邮政编码。这时,你会感到一切都乱了。老板要求网站要在几小时内恢复正常工作。然而,你已经没有时间重建数据库。程序员可以做什么?使用黑客手段把这位客户的邮政编码由base 64的数字格式改为base 10格式?或者设置一个使用转义编码的辅助表格,用来说明真正的邮政编码或者其他?危险的黑客无处不在,但你没有时间来搞定它。

MySQL的关联规则让每个人都诚实和谨慎,但它能强制我们避开易受攻击和欺骗的麻烦。
 


3、存储引擎混乱


总体来说,Mysql的存储引擎接口定义还算良好的。MySQL不是实际上的同一的数据库。它是由几个数据库组成,它们的大多数细节都被统一的表面掩盖了。开始时有一个MyISAM引擎,它很快但在前后一致上不能做到完备。有时你需要速度并且可以接受不一致的结果时是很好的。

当人们需要更多时,具备完整事务支持的Inno DB出现了。但这还不够。现在,它可能有20种存储引擎的选择——这足以使一个数据库管理员疯狂。当然,有时在不同的存储引擎之间切换而不必重写你的SQL是很好的,但是切换后总会带来混乱。这个表格我选择的引擎是MyISAM还是innoDB呢?或者,我决定输出的数据是CSV格式的吗?
 


4、JOIN联合查询


曾经,将数据分表保存是计算机科学史上的伟大创新。分开后的表不仅结构简单,使用上也简化了许多。但它却需要使用join语句来进行查询。

sql通过一系列join构建的复杂查询将开发者推入了困惑与绝望的深渊。而且存储引擎也需要以最优的方式来高效地解析join语句。开发者需要绞尽脑汁编写查询语句,然后数据库对其进行解析。

这就是很多注重运行速度的开发者放弃数据分表转而使用不规范数据表的原因。不区分数据实体,将所有数据保存到一个大表中——以避免复杂的查询。这样确实很快,并且服务器也不会耗尽内存。

现在的磁盘空间很廉价。8TB的磁盘已经在售,更大容量的也将上市。我们不再需要为使用join而绞尽脑汁了。
 


5、分支的混乱


毋庸置疑,一个可靠的、得到良好支持的MySQL分支,可以带来竞争和选择,但是它也引起困惑和混乱。更糟糕的是,一个称为MariaDB的MySQL分支,由Monty Widenius维护着。他同样也在参与编写MySQL。那么,Maria DB是真正独立的值得我们拥护的吗?或者它是MySQL?我们是否应该坚持使用由创建原始mysql数据库的组织运营的核心代码?或者我们应该加入那些被认为更聪明的,往往很酷的背叛者?

如何获取关于兼容性的信息?虽然Maria DB和MySQL十分相似,但它们之间也有差异。这就是大家一直都在争论它的原因。在性能方面,在我们查询的范围内,在两个阵营中,也许它们的工作方式相同,但也许不同,也许将来会不同。
 


6、开发MySQL的动机


虽然MySQL是一款成功的开源产品,但它仍属于商业中的一款产品,专业开发者需要靠它来获得利益,当然,最直接的利益就是薪资。当大多数用户在持续地享受开源许可证带来的最佳体验时,毫无疑问这家公司还在为赚取足够的钱来维持运营而努力。这导致自由代码在“社区版”和出售给企业的完整产品之间产生了奇怪的分岐。

我们应该对这款产品付钱吗?这种在社区版开展经营的行为是否公平?企业版中额外的功能是不是一个噱头,以引诱我们不断付费的呢?这至少说明一点,它是另一些需要回答的问题:选用哪个版本?遵照哪种许可证?选用它的哪个功能集?
 


7、原生JSON支持的缺乏


通过安装MySQL查看其年龄,然后你就知道需要添加哪些驱动程序使它变得可用。MySQL通常在3306端口上通信,一般输出的是它本身难以理解的格式化数据。如果要让你的代码和它通信,你必须添加另一层代码,将MySQL的语言转换成有用的东西。这些层的代码,以库的形式分发,经常需要人们购买一个商业许可证。

现代数据存储层通常直接以JSON通信。虽然MySQL和Maria DB现在有能力解析SQL中的JSON部分,但这还远远不够,原生的JSON接口已经被广泛使用于CouchDB、MongoDB,或任何最新的工具中。
 


8、封闭源和专有模块的兴起


虽然MySQL是开源的,但除了一些在”开源核心“周边开发的一些较新的、非开源的代码和专有模块。程序员也需要赚钱、需要生活,Oracle需要拿它的辛苦成果来换钱,这是一种现实,也是商业的性质。使用MySQL你也不可以免费得到任何东西。

要求MySQL始终坚持在一个很高的标准上,这有点不公平,因为开源的成功可能是一个圈套。它开始可以免费,但并不意味着它可以始终免费。如果企业需要更多新的功能,他们就要通过各种方式付费来获取。有时向Oracle付费,比自己来编写代码要便宜得多。有时商业的、不开源的代码是有意义的。

MySQL虽然作为一个成功的开源系统,但以上这些问题也总不可避免地出现,这就需要我们在它们发生之前有个深刻的认识,才能在今后的应用中避免不必要的麻烦。

部署管理工具:Chef vs Puppet vs Ansible vs SaltStack vs Fabric

开源技术OS小编 发表了文章 • 0 个评论 • 155 次浏览 • 2016-12-28 16:09 • 来自相关话题

Chef,Puppet,Ansible,SaltStack和Fabric的利弊是什么?

今天的生产经常意味着连续部署和分布在世界各地的环境。 当您的基础架构是分散式和基于云的,并且您正在处理在大部分相同的服务器上频繁部署大致相同的服务时,有一种方法来自动化配置和维护一切都是一大福音。 部署管理工具和配置管理工具是为此目的而设计的。 它们使您能够使用配方,剧本,模板或任何术语来简化环境中的自动化和编排,以提供标准,一致的部署。

在此空间中选择工具时,请记住几个注意事项。 一个是工具的模型。 一些需要主客户端模型,其使用集中控制点来与分布式机器通信,而其他人可以或者在更多本地级别上操作。 另一个考虑是你的环境的组成。 一些工具以不同的语言编写,并且对特定操作系统或设置的支持可以不同。 确保您选择的工具与您的环境和您的团队的特殊技能很好地融合在一起可以为您节省很多头痛。

1、Ansible





Ansible是用于在可重复的方式将应用程序部署到远程节点和配置服务器的开源工具。 它为您提供了使用推送模型设置推送多层应用程序和应用程序工件的通用框架,但如果愿意,您可以将其设置为主客户端。 Ansible是建立在playbooks,你可以应用于各种各样的系统部署你的应用程序。
 




这是Ansible Tower仪表板。
 
何时使用:如果起床和快速运行,方便地对你很重要,你不想安装在远程节点或托管服务器代理商,考虑Ansible。 如果你的需要或焦点更多在系统管理员方面,这是很好。 Ansible专注于精简和快速,所以如果这些是你的关键问题,给它一个镜头。
 
价格:有免费的开源版本,付费的Ansible Tower在$ 5,000每年(它给你多达100个节点)支付计划。
 
优点:
基于SSH,因此不需要在远程节点上安装任何代理。使用YAML语法易于学习。Playbook结构简单,结构清晰。具有可变注册功能,可使任务为以后的任务注册变量比一些其他工具更加精简的代码库
 缺点:
不如基于其他编程语言的工具强大。它的逻辑通过它的DSL,这意味着检查文档经常,直到你学习它即使是基本功能,也需要变量注册,这使得更简单的任务更复杂内省很差。 很难看到playbooks里的变量的价值输入,输出和配置文件的格式之间不一致性能和速度有待加强
Ansible介绍视频: https://www.youtube.com/watch?v=iVWmbStE1MM 

2、chef





Chef是配置管理的开源工具,专注于开发方为它的用户群。 厨师作为主客户端模型运行,具有控制主人所需的单独的工作站。 它基于Ruby,用纯Ruby编写的大多数元素。 厨师的设计是透明的,并根据它给出的说明,这意味着你必须确保你的说明是清楚的。
 




Chef DashBoard
 
何时使用:考虑使用Chef的时候需要保证你会使用Git/Ruby 因为书写配置的时候你会用到的。 Chef非常适合以开发为中心的团队和环境。 它对于寻找一个更加成熟的解决方案的企业非常适合异构环境。
 
价格:有免费的开源版本,每月的基础上的价格每节点的标准,保费计划,可以在高音量踏踏实实地分别为$ 6 /节点/月或$ 6.75 /节点/月。
 
优点:
丰富的模块和配置配方集合。代码驱动的方法为您的配置提供更多的控制和灵活性。围绕Git提供强大的版本控制功能。“Knife”工具(使用SSH从工作站部署代理)减轻了安装负担。
 
缺点:
如果你还不熟悉Ruby和过程编码,学习曲线是很陡峭的。这不是一个简单的工具,这可能导致大的代码库和复杂的环境。不支持推送功能。
Chef介绍视频:https://www.youtube.com/watch?v=kDeRHgnuDzc 

3、Fabric





Fabric是在应用程序部署精简SSH一个基于Python的工具。 它主要用于跨多个远程系统运行任务,但也可以使用插件扩展以提供更高级的功能。 Fabric将配置您的系统,执行系统/服务器管理,并自动部署您的应用程序。
 
何时使用:如果你只是在部署自动化领域起步的,Fabric是一个很好的起点。 如果你的环境涉及至少一点点Python,它是有帮助的。
 
价格:免费
 
优点:
擅长部署以任何语言编写的应用程序。 它不依赖于系统架构,而是OS和包管理器。比这个领域的其他工具更简单,更容易部署与SSH进行广泛集成,实现基于脚本的精简
 
缺点:
Fabric是单点故障设置(通常是您运行部署的机器)使用推模型,因此不太适合连续部署模型作为这个空间中的一些其他工具虽然它是用于在大多数语言中部署应用程序的一个很好的工具,但它需要Python运行,因此您的Fabric环境中必须至少有一个Python。
Fabric介绍视频:https://www.youtube.com/watch?v=VmcGuKPpWH8 

4、Puppet





Puppet是在全面配置管理空间长期工具之一。 它是一个开源工具,但考虑到它已经存在多久,它已经被良好的审查和部署在一些最大和最苛刻的环境中。 Puppet基于Ruby,但是使用更接近JSON的定制的域脚本语言(DSL)来在其中工作。 它作为主客户端设置运行,并使用模型驱动方法。 Puppet代码设计作为依赖关系列表,这可以使事情更容易或更混乱,这取决于您的设置。





Puppet企业仪表板
 
何时使用: Puppet是一个不错的选择,稳定性和成熟是你选择的关键因素。 它对于DevOps团队具有异构环境和技能范围的大型企业很有好处。
 
价格:Puppet可以使用免费开源版本,同时也提供收费企业版每年每节点$ 112与批量折扣付费商业企业版本。
 
优点:
通过Puppet Labs建立良好的支持社区。它有最成熟的接口,几乎在每个操作系统上运行。简单的安装和初始设置。在这个空间中最完整的Web UI。强大的报告功能。
 
缺点:
对于更高级的任务,您将需要使用基于Ruby的CLI(这意味着您必须理解Ruby)。支持纯Ruby版本(而不是使用Puppet的定制DSL)正在缩减。由于DSL和一个不专注于简单性的设计,Puppet代码库可能会变得庞大,笨重,难以在更高规模的组织中接纳新用户。与代码驱动方法相比,模型驱动方法意味着更少的控制。
Puppet介绍视频:https://www.youtube.com/watch?v=j8ImF23jZAg 

5、SaltStack





SaltStack(或Salt)是一个基于命令行的工具,可以设置一个主客户端模式还是非集中模式。 Salt基于Python,提供了一种推送方法和一种与客户端通信的SSH方法。 Salt允许对客户端和配置模板进行分组,以简化对环境的控制。
 
何时使用:Salt是一种不错的选择,如果可扩展性和永续性是一个大问题, 它对系统管理员很有好处,因为它的可用性比较好。
 
价格:免费的开源版本,这是基于每年每节点订阅的基础上SaltStack Enterprise版本。 具体定价不在他们的网站上列出(只是“联系我们”链接),但其他人报告每个节点每年150美元起点。
 
优点:
一旦您完成设置阶段,即可轻松组织和使用。他们的DSL是功能丰富,并不是逻辑和状态所必需的。输入,输出和配置非常一致 - 所有YAML。内省是非常好的。 很容易看到Salt内发生了什么。强大的社区。在主模型中具有minions和层级层次的高可扩展性和弹性。
 
缺点:
很难设置和挑选新用户。文档在介绍层面很难理解。Web UI比空间中的其他工具的Web UI更新,更不完整。对非Linux操作系统不是很大的支持。
SaltStack介绍视频:https://www.youtube.com/watch?v=TQjE2I8CrzQ 

Ansible vs. Chef vs. Fabric vs. Puppet vs. SaltStack

使用哪种配置管理或部署自动化工具将取决于您的环境的需求和首选项。 Chef和Puppet是一些较老的,更成熟的选择,使它们适合于那些重视成熟度和稳定性而不是简单性的大型企业和环境。 Ansible和SaltStack是那些寻求快速和简单的解决方案,而在不需要支持quirky功能或大量的操作系统的环境中工作的人的好选择。 面料是小型环境和那些寻求更低升力和入门级解决方案的好工具。
 
英文原文:http://blog.takipi.com/deployment-management-tools-chef-vs-puppet-vs-ansible-vs-saltstack-vs-fabric/  查看全部
chef.puppet_.ansibe_.saltstack_.fabric_.png


Chef,Puppet,Ansible,SaltStack和Fabric的利弊是什么?


今天的生产经常意味着连续部署和分布在世界各地的环境。 当您的基础架构是分散式和基于云的,并且您正在处理在大部分相同的服务器上频繁部署大致相同的服务时,有一种方法来自动化配置和维护一切都是一大福音。 部署管理工具和配置管理工具是为此目的而设计的。 它们使您能够使用配方,剧本,模板或任何术语来简化环境中的自动化和编排,以提供标准,一致的部署。

在此空间中选择工具时,请记住几个注意事项。 一个是工具的模型。 一些需要主客户端模型,其使用集中控制点来与分布式机器通信,而其他人可以或者在更多本地级别上操作。 另一个考虑是你的环境的组成。 一些工具以不同的语言编写,并且对特定操作系统或设置的支持可以不同。 确保您选择的工具与您的环境和您的团队的特殊技能很好地融合在一起可以为您节省很多头痛。


1、Ansible


ansible.png

Ansible是用于在可重复的方式将应用程序部署到远程节点和配置服务器的开源工具。 它为您提供了使用推送模型设置推送多层应用程序和应用程序工件的通用框架,但如果愿意,您可以将其设置为主客户端。 Ansible是建立在playbooks,你可以应用于各种各样的系统部署你的应用程序。
 
AnsibleDashboard.jpg

这是Ansible Tower仪表板。
 
何时使用:如果起床和快速运行,方便地对你很重要,你不想安装在远程节点或托管服务器代理商,考虑Ansible。 如果你的需要或焦点更多在系统管理员方面,这是很好。 Ansible专注于精简和快速,所以如果这些是你的关键问题,给它一个镜头。
 
价格:有免费的开源版本,付费的Ansible Tower在$ 5,000每年(它给你多达100个节点)支付计划。
 
优点:
  • 基于SSH,因此不需要在远程节点上安装任何代理。
  • 使用YAML语法易于学习。
  • Playbook结构简单,结构清晰。
  • 具有可变注册功能,可使任务为以后的任务注册变量
  • 比一些其他工具更加精简的代码库

 缺点
  • 不如基于其他编程语言的工具强大。
  • 它的逻辑通过它的DSL,这意味着检查文档经常,直到你学习它
  • 即使是基本功能,也需要变量注册,这使得更简单的任务更复杂
  • 内省很差。 很难看到playbooks里的变量的价值
  • 输入,输出和配置文件的格式之间不一致
  • 性能和速度有待加强

Ansible介绍视频: https://www.youtube.com/watch?v=iVWmbStE1MM 


2、chef


chef.png

Chef是配置管理的开源工具,专注于开发方为它的用户群。 厨师作为主客户端模型运行,具有控制主人所需的单独的工作站。 它基于Ruby,用纯Ruby编写的大多数元素。 厨师的设计是透明的,并根据它给出的说明,这意味着你必须确保你的说明是清楚的。
 
ChefBoard.jpg

Chef DashBoard
 
何时使用:考虑使用Chef的时候需要保证你会使用Git/Ruby 因为书写配置的时候你会用到的。 Chef非常适合以开发为中心的团队和环境。 它对于寻找一个更加成熟的解决方案的企业非常适合异构环境。
 
价格:有免费的开源版本,每月的基础上的价格每节点的标准,保费计划,可以在高音量踏踏实实地分别为$ 6 /节点/月或$ 6.75 /节点/月。
 
优点
  • 丰富的模块和配置配方集合。
  • 代码驱动的方法为您的配置提供更多的控制和灵活性。
  • 围绕Git提供强大的版本控制功能。
  • “Knife”工具(使用SSH从工作站部署代理)减轻了安装负担。

 
缺点:
  • 如果你还不熟悉Ruby和过程编码,学习曲线是很陡峭的。
  • 这不是一个简单的工具,这可能导致大的代码库和复杂的环境。
  • 不支持推送功能。

Chef介绍视频:https://www.youtube.com/watch?v=kDeRHgnuDzc 


3、Fabric


fabric.png

Fabric是在应用程序部署精简SSH一个基于Python的工具。 它主要用于跨多个远程系统运行任务,但也可以使用插件扩展以提供更高级的功能。 Fabric将配置您的系统,执行系统/服务器管理,并自动部署您的应用程序。
 
何时使用:如果你只是在部署自动化领域起步的,Fabric是一个很好的起点。 如果你的环境涉及至少一点点Python,它是有帮助的。
 
价格:免费
 
优点:
  • 擅长部署以任何语言编写的应用程序。 它不依赖于系统架构,而是OS和包管理器。
  • 比这个领域的其他工具更简单,更容易部署
  • 与SSH进行广泛集成,实现基于脚本的精简

 
缺点:
  • Fabric是单点故障设置(通常是您运行部署的机器)
  • 使用推模型,因此不太适合连续部署模型作为这个空间中的一些其他工具
  • 虽然它是用于在大多数语言中部署应用程序的一个很好的工具,但它需要Python运行,因此您的Fabric环境中必须至少有一个Python。

Fabric介绍视频:https://www.youtube.com/watch?v=VmcGuKPpWH8 


4、Puppet


Puppet.png

Puppet是在全面配置管理空间长期工具之一。 它是一个开源工具,但考虑到它已经存在多久,它已经被良好的审查和部署在一些最大和最苛刻的环境中。 Puppet基于Ruby,但是使用更接近JSON的定制的域脚本语言(DSL)来在其中工作。 它作为主客户端设置运行,并使用模型驱动方法。 Puppet代码设计作为依赖关系列表,这可以使事情更容易或更混乱,这取决于您的设置。

PuppetBoard.jpg

Puppet企业仪表板
 
何时使用: Puppet是一个不错的选择,稳定性和成熟是你选择的关键因素。 它对于DevOps团队具有异构环境和技能范围的大型企业很有好处。
 
价格:Puppet可以使用免费开源版本,同时也提供收费企业版每年每节点$ 112与批量折扣付费商业企业版本。
 
优点:
  • 通过Puppet Labs建立良好的支持社区。
  • 它有最成熟的接口,几乎在每个操作系统上运行。
  • 简单的安装和初始设置。
  • 在这个空间中最完整的Web UI。
  • 强大的报告功能。

 
缺点:
  • 对于更高级的任务,您将需要使用基于Ruby的CLI(这意味着您必须理解Ruby)。
  • 支持纯Ruby版本(而不是使用Puppet的定制DSL)正在缩减。
  • 由于DSL和一个不专注于简单性的设计,Puppet代码库可能会变得庞大,笨重,难以在更高规模的组织中接纳新用户。
  • 与代码驱动方法相比,模型驱动方法意味着更少的控制。

Puppet介绍视频:https://www.youtube.com/watch?v=j8ImF23jZAg 


5、SaltStack


saltstack.png

SaltStack(或Salt)是一个基于命令行的工具,可以设置一个主客户端模式还是非集中模式。 Salt基于Python,提供了一种推送方法和一种与客户端通信的SSH方法。 Salt允许对客户端和配置模板进行分组,以简化对环境的控制。
 
何时使用:Salt是一种不错的选择,如果可扩展性和永续性是一个大问题, 它对系统管理员很有好处,因为它的可用性比较好。
 
价格:免费的开源版本,这是基于每年每节点订阅的基础上SaltStack Enterprise版本。 具体定价不在他们的网站上列出(只是“联系我们”链接),但其他人报告每个节点每年150美元起点。
 
优点
  • 一旦您完成设置阶段,即可轻松组织和使用。
  • 他们的DSL是功能丰富,并不是逻辑和状态所必需的。
  • 输入,输出和配置非常一致 - 所有YAML。
  • 内省是非常好的。 很容易看到Salt内发生了什么。
  • 强大的社区。
  • 在主模型中具有minions和层级层次的高可扩展性和弹性。

 
缺点:
  • 很难设置和挑选新用户。
  • 文档在介绍层面很难理解。
  • Web UI比空间中的其他工具的Web UI更新,更不完整。
  • 对非Linux操作系统不是很大的支持。

SaltStack介绍视频:https://www.youtube.com/watch?v=TQjE2I8CrzQ 


Ansible vs. Chef vs. Fabric vs. Puppet vs. SaltStack


使用哪种配置管理或部署自动化工具将取决于您的环境的需求和首选项。 Chef和Puppet是一些较老的,更成熟的选择,使它们适合于那些重视成熟度和稳定性而不是简单性的大型企业和环境。 Ansible和SaltStack是那些寻求快速和简单的解决方案,而在不需要支持quirky功能或大量的操作系统的环境中工作的人的好选择。 面料是小型环境和那些寻求更低升力和入门级解决方案的好工具。
 
英文原文:http://blog.takipi.com/deployment-management-tools-chef-vs-puppet-vs-ansible-vs-saltstack-vs-fabric/ 

国内开源镜像站汇总分享

开源技术OS小编 发表了文章 • 0 个评论 • 122 次浏览 • 2016-12-27 17:43 • 来自相关话题

企业开源站

搜狐开源镜像站:http://mirrors.sohu.com/  
网易开源镜像站:http://mirrors.163.com/  
阿里开源镜像站:   http://mirrors.aliyun.com/ 
首都在线镜像站:http://mirrors.yun-idc.com/  
贝特康姆镜像站:http://centos.bitcomm.cn/  
Centos官方镜像: http://mirror-status.centos.org/  
 
 

大学教学站

中山大学镜像:http://mirror.sysu.edu.cn/ 
山东理工大学:http://mirrors.sdutlinux.org/ 
哈尔滨工业大学:http://run.hit.edu.cn/ 
中国地质大学:http://cugbteam.org/ 
大连理工大学:http://mirror.dlut.edu.cn/ 
西南林业大学 http://cs3.swfu.edu.cn/cs3guide.html 
北京化工大学(仅教育网可以访问),包含 CentOS 镜像:http://ubuntu.buct.edu.cn/ 
天津大学:http://mirror.tju.edu.cn/ 
西南大学:http://linux.swu.edu.cn/swudownload/Distributions/ 
青岛大学:http://mirror.qdu.edu.cn/ 
南京师范大学:http://mirrors.njnu.edu.cn/ 
大连东软信息学院: http://mirrors.neusoft.edu.cn/ 
浙江大学:http://mirrors.zju.edu.cn/ 
兰州大学:http://mirror.lzu.edu.cn/ 
厦门大学:http://mirrors.xmu.edu.cn/ 

北京理工大学:
http://mirror.bit.edu.cn   (IPv4 only)
http://mirror.bit6.edu.cn   (IPv6 only)

北京交通大学:
http://mirror.bjtu.edu.cn   (IPv4 only)
http://mirror6.bjtu.edu.cn   (IPv6 only)
http://debian.bjtu.edu.cn   (IPv4+IPv6)

上海交通大学:
http://ftp.sjtu.edu.cn/   (IPv4 only)
http://ftp6.sjtu.edu.cn   (IPv6 only)

清华大学:
http://mirrors.tuna.tsinghua.edu.cn/   (IPv4+IPv6)
http://mirrors.6.tuna.tsinghua.edu.cn/   (IPv6 only)
http://mirrors.4.tuna.tsinghua.edu.cn/   (IPv4 only)

中国科学技术大学:
http://mirrors.ustc.edu.cn/   (IPv4+IPv6)
http://mirrors4.ustc.edu.cn/  
http://mirrors6.ustc.edu.cn/  

东北大学:
http://mirror.neu.edu.cn/   (IPv4 only)
http://mirror.neu6.edu.cn/   (IPv6 only)

华中科技大学:
http://mirrors.hust.edu.cn/  
http://mirrors.hustunique.com/  

电子科技大学:http://ubuntu.uestc.edu.cn/  
电子科大凝聚工作室(Raspbian单一系统镜像) http://raspbian.cnssuestc.org/  
电子科大星辰工作室(少数小众发布版镜像) http://mirrors.stuhome.net/  
中国linux开源社团: http://mirrors.skyshe.cn/centos/  
 

HongKong

China - Hong Kong     Web Services Ltd.    http://mirror.vpshosting.com.hk/pub/linux/centos/
Hong Kong    01LINK NETWORK SERVICES LIMITED    http://centos.01link.hk/  
Hong Kong    CommuniLink Internet Limited    http://centos.communilink.net/       
Hong Kong    i-System Technology Limited    http://centos.uhost.hk/     
Hong Kong    SunnyVision Limited    http://mirror.sunnyvision.com/centos/          
Hong Kong    The Chinese University of Hong Kong    http://ftp.cuhk.edu.hk/pub/Linux/centos/         
Hong Kong    UDomain Web Hosting Company Ltd.    http://repo.virtualhosting.hk/centos/  
 

PyPi 镜像

豆瓣:http://pypi.douban.com/  
山东理工大学:http://pypi.sdutlinux.org/  
中山大学:http://mirror.sysu.edu.cn/pypi/  
V2EX:http://pypi.v2ex.com/simple/  
 

RubyGems 镜像

中山大学:http://mirror.sysu.edu.cn/rubygems/  
山东理工大学:http://ruby.sdutlinux.org/  
淘宝网:http://ruby.taobao.org/  
 

npm 镜像

cnpmjs:http://cnpmjs.org/  
 
为了为大家提供方便,这里收集了国内的开源站点,如果有错漏缺失之处,欢迎在文章下的评论中指出,然后更新。 查看全部
image.png


企业开源站


搜狐开源镜像站:http://mirrors.sohu.com/  
网易开源镜像站:http://mirrors.163.com/  
阿里开源镜像站:   http://mirrors.aliyun.com/ 
首都在线镜像站:http://mirrors.yun-idc.com/  
贝特康姆镜像站:http://centos.bitcomm.cn/  
Centos官方镜像: http://mirror-status.centos.org/  
 
 


大学教学站


中山大学镜像:http://mirror.sysu.edu.cn/ 
山东理工大学:http://mirrors.sdutlinux.org/ 
哈尔滨工业大学:http://run.hit.edu.cn/ 
中国地质大学:http://cugbteam.org/ 
大连理工大学:http://mirror.dlut.edu.cn/ 
西南林业大学 http://cs3.swfu.edu.cn/cs3guide.html 
北京化工大学(仅教育网可以访问),包含 CentOS 镜像:http://ubuntu.buct.edu.cn/ 
天津大学:http://mirror.tju.edu.cn/ 
西南大学:http://linux.swu.edu.cn/swudownload/Distributions/ 
青岛大学:http://mirror.qdu.edu.cn/ 
南京师范大学:http://mirrors.njnu.edu.cn/ 
大连东软信息学院: http://mirrors.neusoft.edu.cn/ 
浙江大学:http://mirrors.zju.edu.cn/ 
兰州大学:http://mirror.lzu.edu.cn/ 
厦门大学:http://mirrors.xmu.edu.cn/ 

北京理工大学:
http://mirror.bit.edu.cn   (IPv4 only)
http://mirror.bit6.edu.cn   (IPv6 only)

北京交通大学:
http://mirror.bjtu.edu.cn   (IPv4 only)
http://mirror6.bjtu.edu.cn   (IPv6 only)
http://debian.bjtu.edu.cn   (IPv4+IPv6)

上海交通大学:
http://ftp.sjtu.edu.cn/   (IPv4 only)
http://ftp6.sjtu.edu.cn   (IPv6 only)

清华大学:
http://mirrors.tuna.tsinghua.edu.cn/   (IPv4+IPv6)
http://mirrors.6.tuna.tsinghua.edu.cn/   (IPv6 only)
http://mirrors.4.tuna.tsinghua.edu.cn/   (IPv4 only)

中国科学技术大学:
http://mirrors.ustc.edu.cn/   (IPv4+IPv6)
http://mirrors4.ustc.edu.cn/  
http://mirrors6.ustc.edu.cn/  

东北大学:
http://mirror.neu.edu.cn/   (IPv4 only)
http://mirror.neu6.edu.cn/   (IPv6 only)

华中科技大学:
http://mirrors.hust.edu.cn/  
http://mirrors.hustunique.com/  

电子科技大学:http://ubuntu.uestc.edu.cn/  
电子科大凝聚工作室(Raspbian单一系统镜像) http://raspbian.cnssuestc.org/  
电子科大星辰工作室(少数小众发布版镜像) http://mirrors.stuhome.net/  
中国linux开源社团: http://mirrors.skyshe.cn/centos/  
 


HongKong


China - Hong Kong     Web Services Ltd.    http://mirror.vpshosting.com.hk/pub/linux/centos/
Hong Kong    01LINK NETWORK SERVICES LIMITED    http://centos.01link.hk/  
Hong Kong    CommuniLink Internet Limited    http://centos.communilink.net/       
Hong Kong    i-System Technology Limited    http://centos.uhost.hk/     
Hong Kong    SunnyVision Limited    http://mirror.sunnyvision.com/centos/          
Hong Kong    The Chinese University of Hong Kong    http://ftp.cuhk.edu.hk/pub/Linux/centos/         
Hong Kong    UDomain Web Hosting Company Ltd.    http://repo.virtualhosting.hk/centos/  
 


PyPi 镜像


豆瓣:http://pypi.douban.com/  
山东理工大学:http://pypi.sdutlinux.org/  
中山大学:http://mirror.sysu.edu.cn/pypi/  
V2EX:http://pypi.v2ex.com/simple/  
 


RubyGems 镜像


中山大学:http://mirror.sysu.edu.cn/rubygems/  
山东理工大学:http://ruby.sdutlinux.org/  
淘宝网:http://ruby.taobao.org/  
 


npm 镜像


cnpmjs:http://cnpmjs.org/  
 
为了为大家提供方便,这里收集了国内的开源站点,如果有错漏缺失之处,欢迎在文章下的评论中指出,然后更新。

Mac下远程Windows桌面工具(Microsoft Remote Desktop For Windows)

回复

开源技术OS小编 发起了问题 • 1 人关注 • 0 个回复 • 149 次浏览 • 2016-12-27 14:25 • 来自相关话题

如何为Kafka集群选择合适的主题和分区数量

大数据/云计算Ansible 发表了文章 • 0 个评论 • 115 次浏览 • 2016-12-26 00:03 • 来自相关话题

这是许多Kafka用户提出的常见问题。 这篇文章的目的是解释几个重要的决定因素,并提供一些简单的公式。
 

更多的分区提供更高的吞吐量

首先要理解的是,主题分区是Kafka中并行性的单位。 在生产者和代理端,对不同分区的写入可以完全并行完成。 因此,昂贵的操作(例如压缩)可以利用更多的硬件资源。 在消费者方面,Kafka总是将一个分区的数据提供给一个消费者线程。 因此,消费者(在消费者组内)的并行度受所消耗的分区的数量的限制。 因此,一般来说,Kafka集群中的分区越多,吞吐量就越高。

用于选择分区数量的粗略公式基于吞吐量。 你衡量整个,你可以在生产单个分区(称之为P)和消费实现(称为C)。 比方说,你的目标吞吐量吨 。 然后,你需要至少有MAX(T / P,T / C)分区。 人们可以在生产者上实现的每分区吞吐量取决于诸如批处理大小,压缩编解码器,确认类型,复制因子等等的配置。然而,一般来说,可以在10秒的MB /如在此所示单个分区的基准 。 消费者吞吐量通常是与应用相关的,因为它对应于消费者逻辑可以如何快速地处理每个消息。 所以,你真的需要测量它。

虽然可以随着时间增加分区的数量,但是如果使用密钥生成消息,则必须小心。 当发布带密钥的消息时,Kafka基于密钥的散列将消息确定性地映射到分区。 这提供了保证具有相同密钥的消息总是路由到同一分区。 此保证对于某些应用可能是重要的,因为分区内的消息总是按顺序递送给消费者。 如果分区的数量改变,则这样的保证可能不再保持。 为了避免这种情况,一种常见的做法是过度分区。 基本上,您可以根据未来的目标吞吐量确定分区数,比如一两年后。 最初,您可以根据您的当前吞吐量只有一个小的Kafka集群。 随着时间的推移,您可以向集群添加更多代理,并按比例将现有分区的一部分移动到新代理(可以在线完成)。 这样,当使用密钥时,您可以跟上吞吐量增长,而不会破坏应用程序中的语义。

除了吞吐量,还有一些其他因素,在选择分区数时值得考虑。 正如你将看到的,在某些情况下,分区太多也可能产生负面影响。
 

更多分区需要打开更多的文件句柄

每个分区映射到broker中文件系统中的目录。 在该日志目录中,每个日志段将有两个文件(一个用于索引,另一个用于实际数据)。 目前,在Kafka中,每个broker打开每个日志段的索引和数据文件的文件句柄。 因此,分区越多,底层操作系统中需要配置打开文件句柄限制的分区越多。 这大多只是一个配置问题。 我们已经看到生产Kafka集群中,运行的每个broker打开的文件句柄数超过30000。
 

更多分区可能是不可用性增加

Kafka支持群集内复制 ,它提供更高的可用性和耐用性。 分区可以有多个副本,每个副本存储在不同的代理上。 其中一个副本被指定为领导者,其余的副本是追随者。 在内部,Kafka自动管理所有这些副本,并确保它们保持同步。 生产者和消费者对分区的请求都在领导副本上提供。 当代理失败时,该代理上具有leader的分区变得暂时不可用。 Kafka将自动将那些不可用分区的领导者移动到其他一些副本以继续服务客户端请求。 这个过程由指定为控制器的Kafka代理之一完成。 它涉及在ZooKeeper中为每个受影响的分区读取和写入一些元数据。 目前,ZooKeeper的操作是在控制器中串行完成的。

在通常情况下,当代理被干净地关闭时,控制器将主动地将领导者一次一个地关闭关闭代理。 单个领导者的移动只需要几毫秒。 因此,从客户的角度来看,在干净的代理关闭期间只有一小窗口的不可用性。

然而,当代理不干净地关闭(例如,kill -9)时,所观察到的不可用性可能与分区的数量成比例。 假设代理具有总共2000个分区,每个具有2个副本。 大致来说,这个代理将是大约1000个分区的领导者。 当这个代理不干净失败时,所有这1000个分区完全不能同时使用。 假设为单个分区选择新的领导需要5毫秒。 对于所有1000个分区,选择新的领导将需要5秒钟。 因此,对于一些分区,它们的观察到的不可用性可以是5秒加上检测故障所花费的时间。

如果一个是不幸的,失败的代理可能是控制器。 在这种情况下,选举新领导者的过程将不会开始,直到控制器故障转移到新的代理。 控制器故障转移自动发生,但需要新控制器在初始化期间从ZooKeeper读取每个分区的一些元数据。 例如,如果Kafka集群中有10,000个分区,并且从ZooKeeper初始化元数据每个分区需要2ms,则可以向不可用性窗口添加20多秒。

一般来说,不洁的故障是罕见的。 但是,如果在这种极少数情况下关心可用性,则可能最好将每个代理的分区数限制为两个到四千个,集群中的分区总数限制到几万个。
 

更多分区可能会增加端到端延迟

Kafka中的端到端延迟由从生产者发布消息到消费者读取消息的时间来定义。 Kafka仅在提交后向消费者公开消息,即,当消息被复制到所有同步副本时。 因此,提交消息的时间可以是端到端等待时间的显着部分。 默认情况下,对于在两个代理之间共享副本的所有分区,Kafka代理仅使用单个线程从另一个代理复制数据。 我们的实验表明,将1000个分区从一个代理复制到另一个代理可以添加大约20毫秒的延迟,这意味着端到端延迟至少为20毫秒。 这对于一些实时应用来说可能太高。

请注意,此问题在较大的群集上减轻。 例如,假设代理上有1000个分区引导,并且在同一个Kafka集群中有10个其他代理。 剩余的10个代理中的每个仅需要从第一代理平均获取100个分区。 因此,由于提交消息而增加的延迟将仅为几毫秒,而不是几十毫秒。

作为一个经验法则,如果你关心的延迟,它可能是一个好主意,每个经纪人的分区数量限制为100 * b * r,其中b是经纪人在kafka集群的数量和r是复制因子。
 

更多分区可能需要更多的内存在客户端

在最新的0.8.2版本,我们汇合到我们平台1.0,我们已经开发出一种更有效的Java生产商。 新生产者的一个好的功能是它允许用户设置用于缓冲传入消息的内存量的上限。 在内部,生产者缓冲每个分区的消息。 在累积了足够的数据或已经过去足够的时间之后,累积的消息从缓冲器中移除并发送到代理。

如果增加分区的数量,消息将在生产者中的更多分区中累积。 所使用的内存总量现在可能超过配置的内存限制。 当这种情况发生时,生产者必须阻止或丢弃任何新的消息,这两者都不是理想的。 为了防止这种情况发生,需要重新配置具有较大内存大小的生产者。

作为经验法则,为了实现良好的吞吐量,应该在生成器中分配至少几十KB的每个分区,并且如果分区的数量显着增加,则调整存储器的总量。

消费者也存在类似的问题。 消费者每个分区获取一批消息。 消费者消耗的分区越多,需要的内存就越多。 然而,这通常只是不是实时的消费者的问题。
 

总结

通常,Kafka集群中的更多分区导致更高的吞吐量。 然而,人们不得不意识到在总体上或每个代理中具有过多分区对可用性和等待时间的潜在影响。 在未来,我们计划改进一些限制,使Kafka在分区数方面更具可扩展性。
 

翻译原文:https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/  
作者:饶俊 查看全部
kafka.png

这是许多Kafka用户提出的常见问题。 这篇文章的目的是解释几个重要的决定因素,并提供一些简单的公式。
 


更多的分区提供更高的吞吐量


首先要理解的是,主题分区是Kafka中并行性的单位。 在生产者和代理端,对不同分区的写入可以完全并行完成。 因此,昂贵的操作(例如压缩)可以利用更多的硬件资源。 在消费者方面,Kafka总是将一个分区的数据提供给一个消费者线程。 因此,消费者(在消费者组内)的并行度受所消耗的分区的数量的限制。 因此,一般来说,Kafka集群中的分区越多,吞吐量就越高。

用于选择分区数量的粗略公式基于吞吐量。 你衡量整个,你可以在生产单个分区(称之为P)和消费实现(称为C)。 比方说,你的目标吞吐量吨 。 然后,你需要至少有MAX(T / P,T / C)分区。 人们可以在生产者上实现的每分区吞吐量取决于诸如批处理大小,压缩编解码器,确认类型,复制因子等等的配置。然而,一般来说,可以在10秒的MB /如在此所示单个分区的基准 。 消费者吞吐量通常是与应用相关的,因为它对应于消费者逻辑可以如何快速地处理每个消息。 所以,你真的需要测量它。

虽然可以随着时间增加分区的数量,但是如果使用密钥生成消息,则必须小心。 当发布带密钥的消息时,Kafka基于密钥的散列将消息确定性地映射到分区。 这提供了保证具有相同密钥的消息总是路由到同一分区。 此保证对于某些应用可能是重要的,因为分区内的消息总是按顺序递送给消费者。 如果分区的数量改变,则这样的保证可能不再保持。 为了避免这种情况,一种常见的做法是过度分区。 基本上,您可以根据未来的目标吞吐量确定分区数,比如一两年后。 最初,您可以根据您的当前吞吐量只有一个小的Kafka集群。 随着时间的推移,您可以向集群添加更多代理,并按比例将现有分区的一部分移动到新代理(可以在线完成)。 这样,当使用密钥时,您可以跟上吞吐量增长,而不会破坏应用程序中的语义。

除了吞吐量,还有一些其他因素,在选择分区数时值得考虑。 正如你将看到的,在某些情况下,分区太多也可能产生负面影响。
 


更多分区需要打开更多的文件句柄


每个分区映射到broker中文件系统中的目录。 在该日志目录中,每个日志段将有两个文件(一个用于索引,另一个用于实际数据)。 目前,在Kafka中,每个broker打开每个日志段的索引和数据文件的文件句柄。 因此,分区越多,底层操作系统中需要配置打开文件句柄限制的分区越多。 这大多只是一个配置问题。 我们已经看到生产Kafka集群中,运行的每个broker打开的文件句柄数超过30000。
 


更多分区可能是不可用性增加


Kafka支持群集内复制 ,它提供更高的可用性和耐用性。 分区可以有多个副本,每个副本存储在不同的代理上。 其中一个副本被指定为领导者,其余的副本是追随者。 在内部,Kafka自动管理所有这些副本,并确保它们保持同步。 生产者和消费者对分区的请求都在领导副本上提供。 当代理失败时,该代理上具有leader的分区变得暂时不可用。 Kafka将自动将那些不可用分区的领导者移动到其他一些副本以继续服务客户端请求。 这个过程由指定为控制器的Kafka代理之一完成。 它涉及在ZooKeeper中为每个受影响的分区读取和写入一些元数据。 目前,ZooKeeper的操作是在控制器中串行完成的。

在通常情况下,当代理被干净地关闭时,控制器将主动地将领导者一次一个地关闭关闭代理。 单个领导者的移动只需要几毫秒。 因此,从客户的角度来看,在干净的代理关闭期间只有一小窗口的不可用性。

然而,当代理不干净地关闭(例如,kill -9)时,所观察到的不可用性可能与分区的数量成比例。 假设代理具有总共2000个分区,每个具有2个副本。 大致来说,这个代理将是大约1000个分区的领导者。 当这个代理不干净失败时,所有这1000个分区完全不能同时使用。 假设为单个分区选择新的领导需要5毫秒。 对于所有1000个分区,选择新的领导将需要5秒钟。 因此,对于一些分区,它们的观察到的不可用性可以是5秒加上检测故障所花费的时间。

如果一个是不幸的,失败的代理可能是控制器。 在这种情况下,选举新领导者的过程将不会开始,直到控制器故障转移到新的代理。 控制器故障转移自动发生,但需要新控制器在初始化期间从ZooKeeper读取每个分区的一些元数据。 例如,如果Kafka集群中有10,000个分区,并且从ZooKeeper初始化元数据每个分区需要2ms,则可以向不可用性窗口添加20多秒。

一般来说,不洁的故障是罕见的。 但是,如果在这种极少数情况下关心可用性,则可能最好将每个代理的分区数限制为两个到四千个,集群中的分区总数限制到几万个。
 


更多分区可能会增加端到端延迟


Kafka中的端到端延迟由从生产者发布消息到消费者读取消息的时间来定义。 Kafka仅在提交后向消费者公开消息,即,当消息被复制到所有同步副本时。 因此,提交消息的时间可以是端到端等待时间的显着部分。 默认情况下,对于在两个代理之间共享副本的所有分区,Kafka代理仅使用单个线程从另一个代理复制数据。 我们的实验表明,将1000个分区从一个代理复制到另一个代理可以添加大约20毫秒的延迟,这意味着端到端延迟至少为20毫秒。 这对于一些实时应用来说可能太高。

请注意,此问题在较大的群集上减轻。 例如,假设代理上有1000个分区引导,并且在同一个Kafka集群中有10个其他代理。 剩余的10个代理中的每个仅需要从第一代理平均获取100个分区。 因此,由于提交消息而增加的延迟将仅为几毫秒,而不是几十毫秒。

作为一个经验法则,如果你关心的延迟,它可能是一个好主意,每个经纪人的分区数量限制为100 * b * r,其中b是经纪人在kafka集群的数量和r是复制因子。
 


更多分区可能需要更多的内存在客户端


在最新的0.8.2版本,我们汇合到我们平台1.0,我们已经开发出一种更有效的Java生产商。 新生产者的一个好的功能是它允许用户设置用于缓冲传入消息的内存量的上限。 在内部,生产者缓冲每个分区的消息。 在累积了足够的数据或已经过去足够的时间之后,累积的消息从缓冲器中移除并发送到代理。

如果增加分区的数量,消息将在生产者中的更多分区中累积。 所使用的内存总量现在可能超过配置的内存限制。 当这种情况发生时,生产者必须阻止或丢弃任何新的消息,这两者都不是理想的。 为了防止这种情况发生,需要重新配置具有较大内存大小的生产者。

作为经验法则,为了实现良好的吞吐量,应该在生成器中分配至少几十KB的每个分区,并且如果分区的数量显着增加,则调整存储器的总量。

消费者也存在类似的问题。 消费者每个分区获取一批消息。 消费者消耗的分区越多,需要的内存就越多。 然而,这通常只是不是实时的消费者的问题。
 


总结


通常,Kafka集群中的更多分区导致更高的吞吐量。 然而,人们不得不意识到在总体上或每个代理中具有过多分区对可用性和等待时间的潜在影响。 在未来,我们计划改进一些限制,使Kafka在分区数方面更具可扩展性。
 


翻译原文:https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/  
作者:饶俊


一个IP的主机上配置Nginx的多个HTTPS虚拟主机

开源技术Ansible 发表了文章 • 0 个评论 • 127 次浏览 • 2016-12-25 22:19 • 来自相关话题

最近公司域名更变,同时,又要新旧域名同时运行。 那么,对于https的域名在同一个IP上如何同时存在多个虚拟主机呢?查看了下nginx手册,有这么一段内容,如下:

如果在同一个IP上配置多个HTTPS主机,会出现一个很普遍的问题:server {
listen 443;
server_name www.example.com;
ssl on;
ssl_certificate www.example.com.crt;
...
}

server {
listen 443;
server_name www.example.org;
ssl on;
ssl_certificate www.example.org.crt;
...
}使用上面的配置,不论浏览器请求哪个主机,都只会收到默认主机www.example.com的证书。这是由SSL协议本身的行为引起的——先建立SSL连接,再发送HTTP请求,所以nginx建立SSL连接时不知道所请求主机的名字,因此,它只会返回默认主机的证书。

最古老的也是最稳定的解决方法就是每个HTTPS主机使用不同的IP地址:server {
listen 192.168.1.1:443;
server_name www.example.com;
ssl on;
ssl_certificate www.example.com.crt;
...
}

server {
listen 192.168.1.2:443;
server_name www.example.org;
ssl on;
ssl_certificate www.example.org.crt;
...
}那么,在同一个IP上,如何配置多个HTTPS主机呢?

nginx支持TLS协议的SNI扩展(Server Name Indication,简单地说这个扩展使得在同一个IP上可以以不同的证书serv不同的域名)。不过,SNI扩展还必须有客户端的支持,另外本地的OpenSSL必须支持它。

如果启用了SSL支持,nginx便会自动识别OpenSSL并启用SNI。是否启用SNI支持,是在编译时由当时的 ssl.h 决定的(SSL_CTRL_SET_TLSEXT_HOSTNAME),如果编译时使用的OpenSSL库支持SNI,则目标系统的OpenSSL库只要支持它就可以正常使用SNI了。

nginx在默认情况下是TLS SNI support disabled。

启用方法:
需要重新编译nginx并启用TLS。步骤如下:# wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz
# tar zxvf openssl-1.0.1e.tar.gz
# ./configure --prefix=/usr/local/nginx --with-http_ssl_module \
--with-openssl=./openssl-1.0.1e \
--with-openssl-opt="enable-tlsext"
# make
# make install查看是否启用:# /usr/local/nginx/sbin/nginx -V
TLS SNI support enabled这样就可以在 同一个IP上配置多个HTTPS主机了。

实例如下:server {
listen 443;
server_name www.baidu.com;
index index.html index.htm index.php;
root /data/wwwroot/baidu/webroot;
ssl on;
ssl_certificate "/usr/local/nginx/conf/ssl/www.baidu.com.public.cer";
ssl_certificate_key "/usr/local/nginx/conf/ssl/www.baidu.com.private.key";
......
}

server {
listen 443;
server_name www.uko.com;
index index.html index.htm index.php;
root /data/wwwroot/www.uko.com/webroot;
ssl on;
ssl_certificate "/usr/local/nginx/conf/ssl/www.uko.com.public.cer";
ssl_certificate_key "/usr/local/nginx/conf/ssl/www.uko.com.private.key";
......
}分享阅读:http://www.ttlsa.com/web/multiple-https-host-nginx-with-a-ip-configuration/ 查看全部
最近公司域名更变,同时,又要新旧域名同时运行。 那么,对于https的域名在同一个IP上如何同时存在多个虚拟主机呢?查看了下nginx手册,有这么一段内容,如下:

如果在同一个IP上配置多个HTTPS主机,会出现一个很普遍的问题:
server {
listen 443;
server_name www.example.com;
ssl on;
ssl_certificate www.example.com.crt;
...
}

server {
listen 443;
server_name www.example.org;
ssl on;
ssl_certificate www.example.org.crt;
...
}
使用上面的配置,不论浏览器请求哪个主机,都只会收到默认主机www.example.com的证书。这是由SSL协议本身的行为引起的——先建立SSL连接,再发送HTTP请求,所以nginx建立SSL连接时不知道所请求主机的名字,因此,它只会返回默认主机的证书。

最古老的也是最稳定的解决方法就是每个HTTPS主机使用不同的IP地址:
server {
listen 192.168.1.1:443;
server_name www.example.com;
ssl on;
ssl_certificate www.example.com.crt;
...
}

server {
listen 192.168.1.2:443;
server_name www.example.org;
ssl on;
ssl_certificate www.example.org.crt;
...
}
那么,在同一个IP上,如何配置多个HTTPS主机呢?

nginx支持TLS协议的SNI扩展(Server Name Indication,简单地说这个扩展使得在同一个IP上可以以不同的证书serv不同的域名)。不过,SNI扩展还必须有客户端的支持,另外本地的OpenSSL必须支持它。

如果启用了SSL支持,nginx便会自动识别OpenSSL并启用SNI。是否启用SNI支持,是在编译时由当时的 ssl.h 决定的(SSL_CTRL_SET_TLSEXT_HOSTNAME),如果编译时使用的OpenSSL库支持SNI,则目标系统的OpenSSL库只要支持它就可以正常使用SNI了。

nginx在默认情况下是TLS SNI support disabled。

启用方法:
需要重新编译nginx并启用TLS。步骤如下:
# wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz
# tar zxvf openssl-1.0.1e.tar.gz
# ./configure --prefix=/usr/local/nginx --with-http_ssl_module \
--with-openssl=./openssl-1.0.1e \
--with-openssl-opt="enable-tlsext"
# make
# make install
查看是否启用:
# /usr/local/nginx/sbin/nginx -V
TLS SNI support enabled
这样就可以在 同一个IP上配置多个HTTPS主机了。

实例如下:
server  {
listen 443;
server_name www.baidu.com;
index index.html index.htm index.php;
root /data/wwwroot/baidu/webroot;
ssl on;
ssl_certificate "/usr/local/nginx/conf/ssl/www.baidu.com.public.cer";
ssl_certificate_key "/usr/local/nginx/conf/ssl/www.baidu.com.private.key";
......
}

server {
listen 443;
server_name www.uko.com;
index index.html index.htm index.php;
root /data/wwwroot/www.uko.com/webroot;
ssl on;
ssl_certificate "/usr/local/nginx/conf/ssl/www.uko.com.public.cer";
ssl_certificate_key "/usr/local/nginx/conf/ssl/www.uko.com.private.key";
......
}
分享阅读:http://www.ttlsa.com/web/multiple-https-host-nginx-with-a-ip-configuration/

编程小白Python入门级神书「推荐」

回复

学习资源OS小编 发起了问题 • 1 人关注 • 0 个回复 • 165 次浏览 • 2016-12-25 21:43 • 来自相关话题

OpenSSH 远程代码执行漏洞安全预警

开源技术Geek小A 发表了文章 • 0 个评论 • 132 次浏览 • 2016-12-22 15:27 • 来自相关话题

概述

12 月 19 日,国外漏洞平台 securityfocus 上发布了最新的 OpenSSH(CVE-2016-10009) 远程代码执行漏洞。官方发布的openssh 7.4版本已经修复此漏洞,同时还修复了CVE-2016-10010、CVE-2016-10011、CVE-2016-10012和CVE-2016-8858。 请检查您使用版本是否在影响范围之内,并及时升级。
 

影响范围

OpenSSH 5.0 – 7.3
 

修复方案

请在升级前做好快照和文件备份,防止出现意外事件
1、升级到官网发布的 OpenSSH 7.4版本
注:升级openssh需要先将OpenSSL和Zlib升级到新版本
 

漏洞详情

CVE-2016-10009:黑客可通过此漏洞执行远程代码,或导致数据泄露。问题出在 ssh-agent ,这个进程默认不启动、只在多主机间免密码登录时才会用到,漏洞利用条件也比较苛刻,攻击者需要有控制agent-sock的权限和文件系统的写权限。官方漏洞评级为“中危”。

可以通过查看系统中是否有名为“ssh-agent ”的进程判断是否启用ssh-agent。

注:OpenSSH 7.4 已于 2016 年 12 月 19 日正式发布,新版本移植了在 Linux、BSD、以及其它类 Unix 平台上 SSH 2.0 协议的完整支持,主要修复了上一个版本中发现的 bug 和安全问题。需注意的是,7.4 版本的各项底层变化,有可能会影响现有的配置。

参考链接
https://www.openssh.com/txt/release-7.4 
http://seclists.org/oss-sec/2016/q4/708  查看全部
openssh.png


概述


12 月 19 日,国外漏洞平台 securityfocus 上发布了最新的 OpenSSH(CVE-2016-10009) 远程代码执行漏洞。官方发布的openssh 7.4版本已经修复此漏洞,同时还修复了CVE-2016-10010、CVE-2016-10011、CVE-2016-10012和CVE-2016-8858。 请检查您使用版本是否在影响范围之内,并及时升级。
 


影响范围


OpenSSH 5.0 – 7.3
 


修复方案


请在升级前做好快照和文件备份,防止出现意外事件
1、升级到官网发布的 OpenSSH 7.4版本
注:升级openssh需要先将OpenSSL和Zlib升级到新版本
 


漏洞详情


CVE-2016-10009:黑客可通过此漏洞执行远程代码,或导致数据泄露。问题出在 ssh-agent ,这个进程默认不启动、只在多主机间免密码登录时才会用到,漏洞利用条件也比较苛刻,攻击者需要有控制agent-sock的权限和文件系统的写权限。官方漏洞评级为“中危”。

可以通过查看系统中是否有名为“ssh-agent ”的进程判断是否启用ssh-agent。

注:OpenSSH 7.4 已于 2016 年 12 月 19 日正式发布,新版本移植了在 Linux、BSD、以及其它类 Unix 平台上 SSH 2.0 协议的完整支持,主要修复了上一个版本中发现的 bug 和安全问题。需注意的是,7.4 版本的各项底层变化,有可能会影响现有的配置。

参考链接
https://www.openssh.com/txt/release-7.4 
http://seclists.org/oss-sec/2016/q4/708 

GIAC 2016全球互联网架构大会PPT分享

回复

开源技术OS小编 发起了问题 • 1 人关注 • 0 个回复 • 157 次浏览 • 2016-12-22 13:42 • 来自相关话题