数据上云的一些槽点，你Get到了吗？

发布时间：2022-09-29 09:31 所属栏目：124 来源：互联网

导读：前阵子参与一个客户的XC方案编制，领导要求XC工作必须和上云作为一件事来做，通过XC加速上云的进展。这就让数据库XC工作变得更为复杂起来了。云厂商提供的RDS大家确实喜欢用，不过XC数据库都无法作为RDS提供出来，云厂商为开发这些数据库的RDS支持开出了一个

　　前阵子参与一个客户的XC方案编制，领导要求XC工作必须和上云作为一件事来做，通过XC加速上云的进展。这就让数据库XC工作变得更为复杂起来了。云厂商提供的RDS大家确实喜欢用，不过XC数据库都无法作为RDS提供出来，云厂商为开发这些数据库的RDS支持开出了一个不低的价格。而将XC数据库部署于裸金属环境后进行云纳管，又不符合这个企业上云的基本IT政策，不被领导认可。这让云管部门大伤脑筋。如果仅仅把XC数据库部署到ECS云主机中，虽然能用，但是能不能用好，大家心里也都没有底。XC数据库厂商信誓旦旦没问题，不过谈到关键大型应用系统的时候，大家又不敢打包票了。

　　向云迁移是近年来IT发展的趋势，这个大方向总是没错的。不过再好的事情也是有局限性和缺点的，所以大部分企业都不会采取一刀切的做法，而是会留下一些余地，因为上云不是最终目的，确保更好的支撑业务才是IT部门上云的目的。如果强行上云并不能很好地支撑业务系统，采用这种比较僵化的一刀切的做法，也不是很妥当的。

　　数据库上云一直是被吐槽的比较多的，虽然目前各大云厂商都有RDS产品，不过国内的RDS产品主要集中在一些开源数据库上，比如MySQL、PG、MongoDB、Redis等。而企业使用的数据库不一定能在这个清单里找到。因此就不可避免地需要把数据库放到ECS云主机里去跑。

　　RDS和跑在ECS里的数据库性能上还是有不少差异的，因为RDS里的数据库是跑在裸金属服务器中的，云平台的云底座对这些裸金属服务器做了纳管支持，这些数据库使用的是本地磁盘，因此在性能上还是有保障的。如果选择高性能SSD盘的RDS，那么IO延时，IO吞吐能力都可以和传统架构的数据库系统相媲美。唯一受限的就是单机的容量。目前在云平台中的RDS都是有规格的，每个规格的RDS不仅仅限制了CPU、内存、IOPS等，也限制了单个数据库的大小。

　　和RDS不同，ECS具有更好的弹性，CPU、内存、存储容量都可以弹性扩充，只不过ECS是完全跑在云底座上的，其存储介质往往使用云底座中的分布式存储，在IO吞吐能力、IO延时方面存在一定的不足。有些云厂商支持ECS集中式存储的LUN，从而获得高性能存储的支持。不巧的事，SAN SWITCH目前找不到国产替代方案，在一些较为严格的XC项目中无法使用这个方案，只能通过分布式存储或者IPSAN来提供存储。当然这也是一个值得吐槽的槽点，SAN SWITCH的使用量是有限的，而且使用年限也很长。如果怕被卡脖子，现在抓紧多买一批也没多少钱，等这批用坏了，国产产品估计也跟上来了。这种片面追求完全自主可控的玩法，也是给XC工作带来了更大的难度。

　　实际上对于数据库上云的吐槽，还是很多的。前阵子在flashdba网站上看到一个Oracle OCM收集的对于数据库上云的吐槽，十分有同感。今天在这里和大家分享一下。其实老外吐槽的内容和我们差不多，对于业务关键型应用程序工作负载，其特点包括大型、复杂、可靠性要求高、任务关键、敏感、性能要求高……，在本地部署时，它们肯定在专用的高端基础架构上运行。当你要把它们迁移到云上时，肯定会遇到问题的。

　　因为云本质上是一个巨大的离散资源和服务池，可以按需满足你的资源与服务请求。你可以方便的在云上托管一个MySQL实例，也可以快速获得几百台ECS云主机。如果您有预算，云就有办法让您花钱。不过无论您是使用云提供商提供的RDS数据库，还是在ECS上安装数据库软件，您都在与数百个甚至数千个其他系统共享该基础架构、共享可用性能力、共享性能。一旦云出现任何问题，那么这一篮子鸡蛋也都会受到影响，虽然云厂商说云是高可靠的，安全的，这些年公有云的故障也不是个例了。我遇到一个用户，在面对这个难题的时候，选择了一种十分无奈的做法，他们把应用服务器的一半部署在云上，一半部署在云下，数据库的主/备环境分别位于云上和云下。这种做法实际上系统的复杂度和运维的难度都大大增加了。实际上系统上线后，大问题没有，小问题还是频发的。

　　对于能够IOE环境中通过彻底改造迁移的系统，上云还是比较容易的。而对于一些暂时无法进行全面改造的系统，那么就只有基础设施迁移这一条路可走了。而这种迁移往往也面临一些大坑。

　　首先我们会遇到IO的巨大挑战。以往Oracle等大型数据库系统依靠集中式存储或者本地高性能硬盘的IO低延时来确保其稳定与高性能的提供服务。而这一切在云上似乎很难得到保证。在云中获得大量计算能力相对容易。但是如果你要求读取和写入非常快、并且在可预测的响应时间完成，云平台就不一定能够很好的给予支撑了。如果IO延迟、IOPS 或吞吐量是十分关键的，那么你可能就会遇到比较难以解决的问题。

　　一些公有云的用户都会有这种感受，并不是云厂商不能提供这些能力，而是你的钱袋子不足以购买到这些能力。很多公有云用户都有这种感受，那就是性能和成本是一枚硬币的两个面，你很难一眼看到所有的东西。我们可以在公有云上去选你所有需要的菜，不过大多数用户在点菜时都遇到过类似身材不是很标准的人买衬衫时的尴尬。就像我这种偏胖的人，是很难买到合适的衬衫的，领子和胸围合适的衬衫往往袖子就长了点，而袖子合适的衬衫往往就太贴身了。

　　在云平台上点菜也是如此，S号的云主机可能是40美金，M号的要120，而L号的最划算，只要160，不过这不是我需要的，我需要穿XXL，什么？你必须为XXL支付400美金。

　　实际上这还是好的，只要你付得起钱，你就可以很快获得你所需要的衬衫。过度的配置会让你有限的预算更加雪上加霜。云厂商的RDS或者ECS就像是餐厅里配好的菜肴，你想要辣子鸡丁里多点鸡丁，少点辣椒是没办法的，CPU，内存，IO能力往往都是配套提供的，你无法按需选取。如果你想要一个3万IOPS的存储系统，不好意思，云厂商的存储系统是按照每个GB来配置的，你要买这么多的IOPS，必须购买5TB的云存储才能获得。而有可能你只需要在上面部署一个500GB的数据库。

　　目前谷歌和亚马逊已经开始提供更为精细的价格体系，可以通过为IOPS额外付费来避免此类问题出现，这是一个很好的现象。

　　如果说这一切发生在公有云上，那对于用户来说，只能默默地接受。而事实上我在很多私有云环境中也看到了类似的情况。云管部门为了便于管理，也像公有云一样，推出了一系列的标准化的产品，你只能从菜单中点选有限的选项，和公有云用户没有太大的区别。云运营部门并不了解数据库应用的需求和特点，他们只是一厢情愿地进行管理。于是在公有云上发生的一切，在自建的私有云上并没有得到解决。

（编辑：ASP站长网）