阿里云基础组件-RAM/VPC/SLB实战

背景简介：

1. 我公司是由多个子公司组成，相互之间有内部阿米巴结算流程，由于阿里云还不支持按业务分组结算，为避免各子公司业务费用计算有误，所以在阿里云创建了多个子公司账号
2. 阿里云原来只有经典网络，在2016年VPC方案逐渐成熟后，公司开始考虑将原私有云上的业务迁移到阿里云上，涉及各类产品项目300多个，云主机1000台左右，原私有云上的一些运维系统，如日志收集服务，发版服务，内部DNS，监控系统等等都需要调用阿里接口重做，难点如下：
   1. 业务量庞大，业务之间结构错综复杂
   2. 阿里云的某些接口目前并不开放，导致一些系统的功能点无法实现
   3. 运维流程、标准必须按照阿里云重新规范定义

 

阿里云运维管理

一、阿里云平台账号管理；阿里云账号管理是一个树形结构，分三级：

第一级：总账户，用于管理阿里云上所有子公司开的父账号，便于集中化管理（但是目前阿里云上还未实现到这一级，根据现在这一需求对客户越来越迫切，未来阿里云肯定会上）

第二级：父账号，也就是我们在阿里上目前注册的账号

第三级：子账号，子账号的出现也是顺应客户的需求、以及自身发展来的，随着阿里云上的产品越来越丰富，项目中应用也越来越广，如果开发、运维都用同一账号，显然安全没办法保障，因此必须缩小权限范围

示例：

1. 在平台创建子用户[email protected],不启用"access_key"，并打开"登录控制台"
2. 创建应用子用户test2，启用"access_key"，将生产的key保存好，不打开"登录控制台"，可通过这个账号调取oss test-bucket，按照阿里的文档，之所有这样是因为：

                                当您的应用系统需要访问云资源时，您应该为应用系统配置一个独立的RAM用户账号的AK，而不要使用主账号的AK。因为主账号的AK拥有"root权限"，它可  

                                以控制您的所有阿里云资源操作，一旦泄露将会导致风险不可控 —— 这会导致您的所有资源或数据被他人控制。

                      3.新建一个dev-team1开发组，建刚才的子用户加入这个组，以便授权时通过给组授权来集中管理

                      4.最后自定义授权策略，这里定义了两个策略:

                                   1）、让test1这个用户只能管理4台ecs机器，1个oss test-bucket，其他的机器不允许操作

                                   

                                  

                                   2）、让test1与test2用户可访问oss test2-bucket，其他的bucket没有权限操作，当然通过程序调用时，test账号由于没有access_key，因此无法获取到对象，只有test2用户才可以。

                                  

 

二、阿里云VPC网络管理；阿里云的VPC实现相对起步较晚，以前阿里云只有经典网络，所有账户下的机器都在一个大通铺网络中，虽然内部有网络隔离，但缺点如下：

1. 给人的感觉是，里面肉鸡很多，机器经常莫名的被人攻击，安全得不到保障；
2. 有的公司想做混合云，根本没办法拉专线把自己账户下所有机器跟IDC打通
3. 不绑公网地址，这个机器就没办法出网

 

阿里云刚出VPC时，没有NAT网关，当时内部机器要出网，还需要阿里协助开通HAVIP（高可用虚IP）功能，具体实现方式是开通一主一备两台ECS作默认网关（如下图1）；而现在这一功能在平台上包装成了下图2的形式沿用至今。当然现在NAT网关终于出了，不过因为某些原因暂未使用

（图1）

（图2）

 

解决了机器出网的问题，又产生了新的问题。同一租户内的两个VPC网络如何打通，不同租户下的VPC网络又如何打通，同时有些公司自建IDC，IDC与阿里VPC网络如何打通？

如图3，该图有两个阿里账户，分别是账户A，账户B，账户A有两个VPC网络，分别是10.126.0.0/16,192.168.32.0/20;账户B只有一个VPC网络段10.126.0.0/16（两个账户下子网段不同）。一共三个虚拟路由器，三条高速通道，无论哪个VPC中的网络段，想访问其他的段，只需添加对应的路由信息即可，高速通道很好的解决了我们前两个问题。至于拉专线，一定要规划好网段，只需与一个账户下的专有网络打通，后面的就容易了。

图3

 

1. 阿里云负载均衡，这里提一个新功能——七层转发。

   

 

很多人可能遇到这样一个问题，一个项目有一些公开的API是被其他项目调用的，因为某些原因，这部分未独立成一个域名，两组api共用一个域名（如下图）。我们曾经遇到GLY-NGINX因为大量下载，并启用了nginx缓存服务，导致CPU使用率很高，影响了公开接口的调用，从而导致其他业务受到影响，那阿里新出的SLB七层转发，实现分流把所有公开接口通过策略转发到了另一组nginx上就解决了该问题

（原来的结构）

（现在的结构）

使用方法：

1. 新建两个虚拟服务组，分别是uc-nginx，gly-nginx，两个组里分别包含一台nginx ecs
2. 在配置监听-使用虚拟服务器组时选gly-nginx，也就是默认走gly-nginx组的nginx代理
3. 添加转发策略，如下图所示

 

结束语：

很多公司以前在IDC自建过私有云，但是由于私有云技术、人员、投入达不到一定程度，可靠性就会非常差，后面就慢慢转投公有云。以前领导问我选公有云还是私有云，当时出于私有云的流行，也想探索一番，经过了三年，发现干的真的很累，由于投入不足，既要维护上面的业务，又要维护平台，反而最后两边都没做好；经过反思，我们发现：

1. 经过核算，以我们的业务量，如果在公有云上，投入成本反而比私有云低。
2. 以前公有云发展不太成熟，但是从近两年看阿里云，发展确实比较迅猛
3. 不管什么项目我们的重点应该是做好业务运维，其他的（IDC，服务器，网络，平台）如果因为一些客观问题做不好，就应该果断放弃，让公有云帮我们保障底层，从而能将更多的人力、物力集中到业务运维上，这也是为什么即使我们现在迁移阿里云难度不小，也要转的原因。