你好,游客 登录 注册 发布搜索
背景:
阅读新闻

配置和使用Pivotal Cloud Foundry中的HAPorxy详解

[日期:2015-04-16] 来源:云计算实务博客  作者: [字体: ]

  Pivotal使用HAProxy作为其访问入口,当然是允许使用其他负载均衡软件或硬件进行替换的。不过,基于怕麻烦和强迫症,个人还是用了HAProxy到最终的生产环境。为了满足特定的应用需求和可靠性需求,对负载均衡这一层做了一定的配置,本文通过四个案例共享这些经验。

  如何配置和使用Pivotal Cloud Foundry里的HAPorxy

  为不同应用分配不同的HAProxy

  Pivotal Cloud Foundry的配置界面中,HAProxy允许配置多个IP(同时需要在资源尺寸页配置相同个数的HAProxy虚拟机),这样一个CF就拥有了多个入口。可以通过管理员的人脑,对运行在这套CF上不同应用按照负载和安全的考量,分配到不同的HAProxy上。具体实例如下:

  假定为PCF配置了两个HAProxy(10.20.30.40和10.20.30.41),在DNS上,默认将*.pcf.mydomain.com子域分配给了这个PCF,指向了10.20.30.40。此时,如果应用app1域名为app1.pcf.mydomain.com,则该应用的访问将通过 10.20.30.40进入PCF。

  这时如果这个应用app1需要使用域名app1.mydomain.com,并且负载很大和/或可靠性要求高,则可以在DNS上将app1.mydomain.com指向10.20.30.41,然后cf create-domain org1 mydomain.com创建域名(如果这个域名整个CF都要用,那就用cf create-shared-domain),然后用cf map-route app1 mydomain.com -n app1为这个应用增加一个新的域名。

  此时,通过app1.mydomain.com和app1.pcf.mydomain.com都可以访问这一应用,但是前者通过10.20.30.41进入PCF,后者通过10.20.30.40进入PCF。

  为同一HAProxy上的不同域名配置SSL证书并自动访问https

  PCF可以生成个自签名的域名给分配给自己的子域,但实际生产中使用证书肯定不会是自签名的,而且多数也不会是整个子域的域名,而是单独的域名,还是针对前文的实例,增加如下需求:另一个应用app2与app1属于同一系统,需要使用域名 app2.mydomain.com,app1.mydomain.com和app2.mydomain.com均有各自的SSL证书,同时二者均要求禁止http访问。

  此时可以将DNS上app2.mydomain.com指向10.20.30.41,然后登陆10.20.30.41这个HAProxy的OS(用户名为vcap,密码可以在Pivotal Operation Manager的界面上找到),进行HAProxy配置。

  对于自动跳转https的需求,可以通过修改/var/vcap/jobs/haproxy/config/haproxy.config里的http-in完成。

  frontend http-in mode http bind :80 option httplog option forwardfor reqadd X-Forwarded-Proto:\ http acl is_app1_mydomain_com hdr(host) -i app1.mydomain.com redirect location https://app1.mydomain.com:443 if is_app1_mydomain_co acl is_app2_mydomain_com hdr(host) -i app2.mydomain.com redirect location https://app2.mydomain.com:443 if is_app2_mydomain_com default_backend http-routers

  对于多个证书的需求,可以通过修改/var/vcap/jobs/haproxy/config/haproxy.config里的https-in完成。将需要的证书上传到这台HAProxy,并在配置文件中添加即可,证书文件支持的格式请参见/var/vcap/jobs/haproxy/config/cert.pem。

  frontend https-in mode http bind :443 ssl crt /var/vcap/jobs/haproxy/config/cert.pem crt /var/vcap/jobs/haproxy/config/app1.mydomain.com.pem crt /var/vcap/jobs/haproxy/config/app2.mydomain.com.pem option httplog option forwardfor option http-server-close reqadd X-Forwarded-Proto:\ https default_backend http-routers

  多层负载均衡满足安全需求和业务需求

  企业的安全及防火墙策略对PCF来说是个灾难,当然现在的版本已经有Availability Zone来覆盖这一需求,但是下面这种需求还是难以实现:PCF部署在生产网络,但是需要被互联网访问,安全策略仅允许DMZ网络对外提供服务,因此需要做个脱裤子放屁的事儿是PCF可以从internet访问。还以上例为基础,app1和app2均需要互联网访问(将定DMZ网络中存在可用的负载均衡设备50.60.70.100和50.60.70.101):

  首先获取一个DMZ网段的IP,如50.60.70.80,开通负载均衡设备50.60.70.100和50.60.70.101访问PCF的对外IP的10.20.30.41的80和443端口,将10.20.30.41的80和443端口在DMZ负载均衡设备上负载均衡为50.60.70.80的80和443,将50.60.70.80的80和443端口NAT成公网的80和443,并返回需要的域名(比如app1.bjsdns.mydomain.com、app2.bjsdns.mydomain.com等),在DNS中把app1.bjsdns.mydomain.com、app2.bjsdns.mydomain.com做别名成app1.mydomain.com和app2.mydomain.com,就大功告成了。

  让CF与普通Tomcat应用服务一块工作

  对于企业内部的私有PaaS来讲,PCF中最让人担心的技术就是PCF的运行环境架构(包含负载均衡和自动弹性)。下面的方案可以屏蔽使用互联网技术带来的新技术不确定性风险,使私有PaaS为实时业务系统提供服务成为可能。这个方案通过将应用服务负载均衡到IaaS资源,确保在PCF的整个运行环境框架出现问题时,可做到用户无感知的故障恢复。具体细节如下:

  1、在PCF中(比如分配10个应用实例,假定应用名称为app1)和使用IaaS虚拟机单独部署的多个Tomcat节点(比如2个)中部署相同应用代码。

  2、在PaaS中使用如下命令创建域(比如mydomain.com),创建应用域名(app1.mydomain.com),绑定应用域名(app1.mydomain.com绑定到应用app1):

  cf create-domain org1 mydomain.com cf map-route app1 mydomain.com -n app1

  3、在负载均衡设备中配置virtual service(比如50.60.70.80),其对应的real service为PaaS环境的入口IP(比如10.20.30.41)和其他使用IaaS虚拟机单独部署的多个Tomcat节点,单独Tomcat节点的权重为1,PaaS入口IP的权重为其为此应用分配的应用实例个数(10)。

  4、在DNS中将应用域名(app1.mydomain.com)配置为负载均衡设备上的virtual service IP(50.60.70.80)。

  5、当用户访问app1.mydomain.com,DNS将解析到负载均衡设备,负载均衡设备会根据策略和权重将请求负载均衡到单独的Tomcat或PaaS入口IP上,如果到了PaaS入口IP上,PaaS将根据客户端访问的域名在此进行解析,并根据策略将请求route到应用app1的10个应用实例上。

收藏 推荐 打印 | 录入:574107552 | 阅读:
相关新闻      
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款