zoukankan      html  css  js  c++  java
  • 浅谈服务器虚拟化

      得益于体系架构和制造工业不断发展带来的红利,单台服务器具备了更多的资源和运算能力。从早期一台服务器一个应用,到如今多个应用共用一台服务器,背后是不断加码的参数。存储容量、CPU运算频率、主板带宽等等,都在每时每刻得到不同程度的发展。在花差不多的钱,拥有的设备却能够做更多的事情,或者说在保持现有设备数量的基础对设备进行升级,那或许会造成不同程度的浪费。一个简略的想法就是合并。

      在以往,笔者会通过共享服务器的方式部署不同的应用,这样可以减少设备的数量,降低设备维护的代价。这种方式起先还是挺有效的,毕竟应用规模和管理人员都相对较少,由于都在一起办公,协调起来倒也方便。一个服务器承载56个小规模的应用是绰绰有余的,甚至随即设备的不断升级更替,同等规模的应用能够更多的聚集在一台设备上。这样的情况还是很让人满足的,毕竟这样一种方式一直再帮助我解决着当前的各类问题。直至现在,我也完全无法肯定的告诉你,我的服务器运行了多少个应用;但我想说,它们被维护得不错,这可能是种奇迹,如果没有应用管理员之间便捷的交流,简单一致的部署方式,一切将难以实现。

    回想起来,如果团队、应用、规模不发生改变,那么通过管理可以回避虚拟化的使用。但这真的只是假设。团队问题优先遭遇问题,人员发生了增加和调动,新的想法被加入,导致一些新的部署想法的产生。任何可行性的想法没有孰对孰错,当时我的准则只要切实可行,总是予以支持,这其实为造成应用部署管理的风险。后来逐渐演变为部分应用迁移到新的服务器上,服务器维护的事情开始增多。

      应用的增长貌似是大数据时代的一种必然,网络数据已指数级的方式增长,部分应用开始不满足于共享的存储。独立、海量、安全的存储要求被提出,与之相对应的便是应用开始以多线程或并行的方式运行于服务器上,以便处理与之对应的数据量。

    当时,唯一的惊喜是,我不需要虚拟化。因为从服务器使用率的角度考量。单个应用的规模,包括程序的框架和代码的规模,都与单台服务器的处理规模相适应,设置出现需要多台服务器协同工作才能够完成处理任务。

      说了这么多,我只想表述,服务器虚拟化可能不是我所想要的。借助分布式和集群,应用能够抽象的运行在多台服务器之上。相比硬件虚拟化,软件或是平台的虚拟化可能更适合应用。应用最好是简单的,像早期,服务器资源总是领跑于应用,但如今却是相反。此时不等不借助于平台来解决这种不对称问题,寻求PAAS的解决途径成为确切的需求。那么服务器的虚拟化的意义何在?

      将单个服务器切分成多个独立的部分,寻求利用的高效率。这样的方式与使用传统的对于多核无法充分利用的应用更为贴切。在并行和多线程的问题思考上,程序员应该更改软件的规模,以此寻求同服务器相对应的处理能力。

      这或许是我心目中软件和硬件共同增长的高效模式,但这会对程序员和应用的架构充满更多的考量和困难。而如今的IAAS还无法通过服务器虚拟化将多台服务器虚拟成一台,促成运算能力和存储的叠加,往往当从IDC或是云技术服务商取得网络的虚拟资源后,还是需要借助应用平台聚集运算能力。

      服务器虚拟化,包括如OpenStack,虽然在资源管理上形成了较好的方式,倒依旧没有降低应用的规模,虽然已经看到海量式的存储,提供可以无限增长的存储空间,但对于应用而言,背后是以数据的传递为代价而换得的通用的网络存储方案。这种存储方式是否对于应用一定是最好的,这还需要实践去验证。我想,在今后,除了现如今看到的使用与IDC之类的服务器虚拟化方案,更多的服务器虚拟化必将与具体应用相结合,并形成IT技术强大的生成了,这一切可能的东西或是IAAS+PAAS,服务器虚拟化与应用虚拟化的一种结合。

  • 相关阅读:
    2-SAT模板
    AC自动机
    省选预备营-Day3(图论) 总结
    省选预备营-Day2(分治) 总结
    左偏树(可并堆)总结
    省选预备营-Day1(数据结构) 总结
    OI基础知识
    C++ 堆
    CH4601 普通平衡树
    java 函数形参传值和传引用的区别
  • 原文地址:https://www.cnblogs.com/kathmi/p/2976399.html
Copyright © 2011-2022 走看看