ZStack 核心架构设计使得 99% 的任务异步执行,因此确保了单个的管理节点能够管理十万级的物理服务器,百万级的虚拟机,数万级的并行任务。
架构的创新动力
对于要管理大量的硬件和虚拟机的公有云,伸缩性是IaaS软件要解决的主要问题之一。一个中等规模的数据中心,可能会有50,000台物理服务器,大约1,500,000的虚拟机,举例来说,同时分属于10000用户。虽然,用户不太可能象刷新Facebook页面一样开/关虚拟机,但是IaaS 系统还是会在某个时刻被数千任务拥塞,这些任务有来自API的,还有来自内部组件的。在某些更糟糕的情况下,一个用户可能会等一个小时才能创建虚拟机,就是因为系统线程池只有1000,而等待处理的任务有5000个。
问题
首先,我们明确反对某些文章中的观点,针对 IaaS 伸缩性问题归结于,其声称 “支撑基础,特别是数据库和消息代理是 IaaS 伸缩性的问题的罪魁祸首”。 这完全是错误的!首先,就数据库的规模来讲,其顶多算是小型和中型;像 Facebook 和 Twitter 这样的互联网巨头,还在拥 MySQL 作为其主数据库。IaaS 的数据难道超过了 Facebook 或 Twitter 吗?完全不可能,他们是十亿级,IaaS 只有百万级(超级数据中心)。其次,相较与 Apache Kafka 或者 ZeroMQ 此类的消息代理服务器,ZStack 所应用的 RabbitMQ 只能算是一个中等伸缩性的代理。但是,其依然可以保持每秒 50.000 的消息处理量。(参考,RabbitMQ 性能测试 , part 2)。难道这在 IaaS 软件系统中做通信还不够吗?完全足够。
其实,IaaS 伸缩性问题的根源在于:任务处理慢。确实是,在 IaaS 软件系统中任务处理非常慢,慢到要有几秒甚至是几分钟才能完成。因此,当系统中全是这种慢慢处理的任务时候,当然就带来了新任务的巨大的延迟。而这种慢处理的任务源于任务路径过长。举例说明,创建虚拟机,一般要经过以下路径 身份服务(service)-->规划器(scheduler)-> 图象服务(service)->存储服务->网络服务->系统管理(Hypervisor); 每个服务都会花费几秒甚至几分钟来操作外部硬件,这就导致了超长的任务处理时长。
同步 vs 异步
传统的 IaaS 软件系统同步处理任务;其往往是基于线程池机制。在此机制下,线程分配给每一个任务,只有当前任务结束后,下一个任务才能被处理。因为,任务处理缓慢,在遇到并行任务的峰值时, 系统由于超过了线程池的极限所以变的很慢,新来的任务只能缓存排队。
解决之道,直观的认为要增加线程池的容量;不过,现在操作系统虽然可以允许程序启动数万的线程,但是调度效率很低。因此,人们就开始做横向扩展,把处理任务分布在类似软件程序上,这些程序驻留在不同操作系统上;因为每个程序拥有其独有的线程池,从而最终增加了整个系统的线程池的容量。但是,以上横向扩展的方案带来了成本问题,其加大了管理的难度,并且,从软件设计的角度讲,集群软件本身也还是不小的挑战。最后,虽然其他的包括数据库,消息代理和外部系统(例如,成千的物理服务器)在内的基础设施有足够的能力来服务于更多的并行任务,但是IaaS软件系统本身变成了云系统的瓶颈。
ZStack 通过异步架构来解决这个问题。如果,我们考虑 IaaS 软件系统和数据中心其他设施的关系,IaaS 软件系统其实是一个中间人的角色。其协调外部系统但不做时实的任务;例如,IaaS 不作具体工作,而是存储系统创建物理卷,镜像系统下载模板,虚拟机由虚拟管理系统创建。那么,IaaS 实际的工作任务就是决定如何分发子任务(sub-tasks)给外部系统。例如,对 KVM,子任务就包括了准备逻辑卷,网络和创建虚拟机,这些子任务都是 KVM 主机实施的;这个过程可能花费5秒钟,其中 IaaS 软件 0.5s, 其余 4.5s 被 KVMz 主机占用。根本上,ZStack 的异步架构确保了不用等这 4.5s,而是仅仅用0.5s 来选择执行的 KVM 主机,然后把任务分发出去。一旦,KVM 主机完成了指定的任务,它就会通知 IaaS 管理软件。以异步架构的方式,一个 100 线程的线程池就能轻松处理数千的并行任务。
ZStack 的异步方式
异步操作在计算机世界很普遍;异步 I/O, AJAX(Asynchronous Javascript And XML 异步的(Javascript 和 XML)是广为人知的例子。然而,要构建异步的全业务逻辑,特别象是 IaaS 这样的集成软件,仍然由很多挑战 。
最大的挑战在于,不是部分,而是全部的组件都要实现异步;例如,如果只是构建一个异步存储服务,但其他相关服务都是同步。那么,整个系统还是没有多少优势。这是因为,要调用存储服务,即使它是异步的,调用方的服务还是不得不等待其结束,那么整个工作流依然是同步的。
图:线程中,业务流程服务要调用存储服务,直到存储服务返回了,线程才能结束。 虽然,存储服务通过异步方式和外部存储系统交互。
ZStack's 异步架构包含三部分:
- 异步消息
- 异步方法
- 异步 HTTP 调用
1. 异步消息
ZStack 使用 RabbitMQ 作为消息总线以便连接各个服务。当某个服务调用另一个服务时,源服务发消息给目的服务并注册一个回调函数,然后马上返回;一旦目的服务完成了任务,它就会通过触发回调函数来回复任务结果。
AttachNicToVmOnHypervisorMsg amsg = new AttachNicToVmOnHypervisorMsg();
amsg.setVmUuid(self.getUuid());
amsg.setHostUuid(self.getHostUuid());
amsg.setNics(msg.getNics());
bus.makeTargetServiceIdByResourceUuid(amsg, HostConstant.SERVICE_ID, self.getHostUuid());
bus.send(amsg, new CloudBusCallBack(msg) {
@Override
public void run(MessageReply reply) {
AttachNicToVmReply r = new AttachNicToVmReply();
if (!reply.isSuccess()) {
r.setError(errf.instantiateErrorCode(VmErrors.ATTACH_NETWORK_ERROR, r.getError()));
}
bus.reply(msg, r);
}
});
单个服务也可以发送一串消息给其他服务 ,并异步的等待回复。
final ImageInventory inv = ImageInventory.valueOf(ivo);
final List<DownloadImageMsg> dmsgs = CollectionUtils.transformToList(msg.getBackupStorageUuids(), new Function<DownloadImageMsg, String>() {
@Override
public DownloadImageMsg call(String arg) {
DownloadImageMsg dmsg = new DownloadImageMsg(inv);
dmsg.setBackupStorageUuid(arg);
bus.makeTargetServiceIdByResourceUuid(dmsg, BackupStorageConstant.SERVICE_ID, arg);
return dmsg;
}
});
bus.send(dmsgs, new CloudBusListCallBack(msg) {
@Override
public void run(List<MessageReply> replies) {
/* do something */
}
}
更进一步,也能发送具有一定并行性的消息串。 比如,一串十个的消息,能够两两发送,第三,第四个消息只有第一,第二个消息收到后在一起发出。
final List<ConnectHostMsg> msgs = new ArrayList<ConnectHostMsg>(hostsToLoad.size());
for (String uuid : hostsToLoad) {
ConnectHostMsg connectMsg = new ConnectHostMsg(uuid);
connectMsg.setNewAdd(false);
connectMsg.setServiceId(serviceId);
connectMsg.setStartPingTaskOnFailure(true);
msgs.add(connectMsg);
}
bus.send(msgs, HostGlobalConfig.HOST_LOAD_PARALLELISM_DEGREE.value(Integer.class), new CloudBusSteppingCallback() {
@Override
public void run(NeedReplyMessage msg, MessageReply reply) {
/* do something */
}
});
2. 异步方法
ZStack 服务,就像以上段一所示,它们之间通过异步消息通信; 对于服务内部,一系列的互相关联的组件,插件是通过异步方法调用来交互的。
protected void startVm(final APIStartVmInstanceMsg msg, final SyncTaskChain taskChain) {
startVm(msg, new Completion(taskChain) {
@Override
public void success() {
VmInstanceInventory inv = VmInstanceInventory.valueOf(self);
APIStartVmInstanceEvent evt = new APIStartVmInstanceEvent(msg.getId());
evt.setInventory(inv);
bus.publish(evt);
taskChain.next();
}
@Override
public void fail(ErrorCode errorCode) {
APIStartVmInstanceEvent evt = new APIStartVmInstanceEvent(msg.getId());
evt.setErrorCode(errf.instantiateErrorCode(VmErrors.START_ERROR, errorCode));
bus.publish(evt);
taskChain.next();
}
});
}
同样, 回调也能包含返回值:
public void createApplianceVm(ApplianceVmSpec spec, final ReturnValueCompletion<ApplianceVmInventory> completion) {
CreateApplianceVmJob job = new CreateApplianceVmJob();
job.setSpec(spec);
if (!spec.isSyncCreate()) {
job.run(new ReturnValueCompletion<Object>(completion) {
@Override
public void success(Object returnValue) {
completion.success((ApplianceVmInventory) returnValue);
}
@Override
public void fail(ErrorCode errorCode) {
completion.fail(errorCode);
}
});
} else {
jobf.execute(spec.getName(), OWNER, job, completion, ApplianceVmInventory.class);
}
}
3. 异步HTTP调用
ZStack 使用了很多代理来管理外部系统。 例如: 管理 KVM 主机的代理,管理 Console Proxy 的代理,管理虚拟路由的代理等等。这些代理都是构建在 Python CherryPy 上的轻量级的 Web 服务器。因为,没有类似 HTML5 中的 Web Sockets 技术就不能实现双向通信,ZStack 就为每个请求,放置了一个回调 URL 在 HTTP 的包头 。这样,任务结束后,代理就能够发送应答给调用者的 URL。
RefreshFirewallCmd cmd = new RefreshFirewallCmd();
List<ApplianceVmFirewallRuleTO> tos = new RuleCombiner().merge();
cmd.setRules(tos);
resf.asyncJsonPost(buildUrl(ApplianceVmConstant.REFRESH_FIREWALL_PATH), cmd, new JsonAsyncRESTCallback<RefreshFirewallRsp>(msg, completion) {
@Override
public void fail(ErrorCode err) {
/* handle failures */
}
@Override
public void success(RefreshFirewallRsp ret) {
/* do something */
}
@Override
public Class<RefreshFirewallRsp> getReturnClass() {
return RefreshFirewallRsp.class;
}
});
通过这三个异步方式,ZStack 已经构建了一个分层架构,保证所有组件能够实现异步操作。
总结
此文,我们阐述了 ZStack 的异步架构,此架构解决了由于并行任务慢而导致的 IaaS 伸缩性问题。在测试中,使用模拟器,在单 ZStack 管理节点中,1000 线程就能轻易处理创建 1,000,000 虚拟机的10,000 个并行任务。除了单节点具有足够伸缩性处理大部分云系统负载的优点外,想要支持高可用行(High Availability)或者朝大规模负载(比如,100,000 并行任务),就必须安装多个管理节点。请参考 ZStack's stateless service in ZStack's Scalability Secrets Part 2: Stateless Services。