将这些环境虚拟化为几个物理盒是一种好习惯吗？
我在网上搜索了一些关于其他组织如何设置环境的想法,但我找不到任何特别有用的东西.我欢迎您指出的任何链接,讨论为中小型公司构建整个企业解决方案.
我刚刚找到这个链接：http://dltj.org/article/software-development-practice/我想找到更多这样的文章,如果有人知道他们可以指出我的任何好的.
在你对我的问题进行投票之前,请发表评论,让我试着解释一下.我可能只是不知道问正确的问题.
解决方法
虚拟化：
你真的想避免服务器蔓延,而现在,一切都是虚拟化的.选择一个平台,允许您快速添加虚拟服务器,并有效地管理它们.我见过的一个趋势是有两个(例如)AIX或VMWare集群,一个用于prod,一个用于非prod.非prod one用于所有开发,测试和登台环境.这些环境非常适合Web服务器或应用程序服务器,但我会尽量避免将大型,不断增长的生产数据库作为VM(至少在Windows上).
当需要与其他服务器共享资源时,这些很容易失控.始终在专用操作系统上运行数据库,永远不要与应用程序或Web服务器共享,除非有充分的理由.无论您使用VM还是硬件都是唯一的问题.
您需要一个可扩展的基础架构,如果您需要,例如移动到集群解决方案,则不会限制您.许多数据库在VM中都可以正常运行,但对于少数最终需要比在VM环境中提供的更多马力的数据库,您会发现自己希望将它们放在raw hardware instead上.
如果您不是在谈论Windows,那么这些指南中的一些将不相关.例如,将大型增长型数据库作为LPAR放在AIX虚拟机管理程序中是一种普遍接受的做法.
存储
没有共享存储,您无法拥有真正的虚拟化(具有VM移动性和主机群集).产品,开发,测试和QA服务器对您的存储看起来都是一样的,但您可能需要花一些时间来寻找优先考虑产品的方法.例如,让一个重税的prod数据库与dev服务器共享磁盘(raid集,池,等等)是一个非常糟糕的主意.开发人员有时会像生产一样努力打击磁盘,最后你需要弄清楚某种测试是否会减慢你的产量.
让知道您存储空间的人坐下来分析所有潜在的瓶颈(端口,缓存,控制器,磁盘等),并尽最大努力防止在prod和非prod之间争用尽可能多的这些瓶颈.
也就是说,有时应用程序人员需要运行开发基准来帮助量化新补丁或其他东西的影响.在这种情况下,您可能需要能够为它们提供类似(或至少可量化的)不同的存储容量.
