还在苦苦搜索资料,论证云服务能够带来哪些优势?今天我们将一同深入探讨如何利用Amazon Web Services来运行一套由数据驱动的网站方案。
云计算技术在过去几年当中无疑迎来了迅猛发展并开始快速走向成熟,如今我们已经能够在其现场部署名单当中看到众多令人信服的成功案例。特别是对于那些可能无力购买服务器及其它硬件设备的小型及初创企业,云服务更是一条能够快速帮我们构建起业务体系的康庄大道。
除了成本优势之外,公有云还提供各类完善的功能特性,诸如可扩展性与资源弹性等等。更重要的是,企业能够利用公有云快速——只需要数分钟,而不再像过去使用物理基础设施时那样需要耗时数周甚至数月——完成基础设施设置。
下面我们将具体探究Amazon Web Services(简称AWS)——目前人气最高的云服务方案之一——的方方面面,从而了解如何利用它帮助小型企业在激烈的市场竞争中占据主动。
AWS生态系统与基本实施条件
值得注意的是,虽然设置一套云部署方案并不像火箭科学那么高端复杂——至少从基础角度来看是如此——但还是会对大家的IT专业背景或者特定技术能力提出一定要求,这也是保障一切得以正确配置的前提条件。举例来说,熟知关于LAMP(即Linux、Apache、MySQL以及PHP)堆栈相关知识的技术人员很可能是负责AWS使用工作的最佳人选。
尽管以通用作为前提性设计思路,AWS通常也能够完成专有云体系的实现工作——这一点已经没有什么争议了。因此,虽然不同云产品之间往往在概念上存在着不少相似之处,但AWS之上的特定使用经验通常无法被直接沿用至微软Azure或者谷歌Compute Engine当中,同时也不能被简单套用到内部部署工作之内。
AWS还提供了多种实施手段,帮助企业客户快速建立并运行多种通用部署场景:事实上,我们通常可以通过不止一种办法实现特定解决方案。不过为了帮助大家更清晰地认知AWS云,我们会尽可能压缩本次服务清单的长度,以免增加不必要的学习难度。
Amazon Web Services主控制台。
#p#
Web托管工作中的部分核心组件
EC2(即Elastic Compute Cloud,弹性计算云)虚拟服务器构成了AWS云部署体系中的主干部分。这些虚拟服务器可以多种不同配置方案进行交付,每套配置都拥有不同的CPU、内存、存储与网络性能水平,且以小时为单位计算使用成本。值得注意的是,某些较为陈旧的实例类型可能随时间推移而陆续被淘汰。
S3(即Simple Storage Service,简单存储服务)是一套对象存储系统,能够容纳最高5TB的单一对象,且可以通过必要的命令行操作、API调用甚至是专门设计以与其协作的桌面应用从任意位置发起网络访问。
EBS(即Elastic Block Store,弹性块存储)提供传统文件系统功能,但使用成本也更高一些。EBS分卷功能与磁盘驱动器类似,能够直接接入服务器并充当存储驱动器,甚至能够在计算实例被关闭之后仍然持续存在。(值得注意的是,大家可以对EC2实例进行设置以确保其被关闭后,对应EBS分卷亦同时被删除。)
RDS(即Relationship Database Service,关系数据库服务)是一项Web服务,能够帮助用户轻松完成关系数据库管理系统(简称RDBMS)的设置、运维以及规模扩展工作。大家可以从多种现有数据库引擎当中作出选择,具体包括MySQL、甲骨文、SQL Server、PostgreSQL以及Amazon Aurora。
Route 53主要面向DNS与域名注册体系。Route 53提供极具竞争力的计费标准,其使用成本往往比某些域名注册商提供的方案更为低廉。从另一方面讲,不少Web托管企业也会以捆绑方式提供类似服务,包括免费提供域名或者在使用的前几年内提供更为低廉的计费方案。
最后,如果大家希望采用AWS云方案,那么我要向各位公布一条好消息:AWS产品目前提供最长达一年的计算实例免费使用周期,此外以上列出的各项产品及服务亦有不同免费机制可供选择。
起步:从机器镜像到选择区域
AWS提供涵盖范围极广的预构建且经过优化的Amazon Machine Images(即Amazon机器镜像,简称AMI),大家可以将其直接载入到刚刚创建完成的实例当中,从而大大简化首个计算实例的启动过程。目前AWS Marketplace当中还包含有大量由第三方创建的镜像方案,而AWS社区亦创建并共享多种公共AMI成果。
在建立自己的云基础设施之前,大家首先需要为这套虚拟基础设施选定一个位置或者说“区域”。在这方面,我们的基本选择思路应当遵循两大原则:要么保证设施位置与大部分用户保持接近,要么保证其与大部分开发人员的物理位置保持接近。在后一种情况下,大家可能会在上传数据及开发网站的过程中获得更为良好的载入时间与速度表现。开发人员与数据库管理员可能会担心不同区域内的数据库副本能否得到确切同步,但没必要太过忧虑——副本之间一定会得到正确同步。最后,某些服务,特别是那些新型或者尚处于beta测试阶段的产品,可能只会在特定区域当中供大家使用。
当然,具体情况取决于大家网站的实际架构。在大多数情况下,使用良好的内容交付网络(简称CDN)服务能够确切模拟我们的部署区域。除了AWS CloudFront CDN之外,大家也可以使用其它备选方案。除此之外,AWS还提供多种工具选项,帮助大家轻松将工作负载迁移至多个区域当中。
最后,值得指出的是,虽然大部分AWS服务的使用成本在各个区域之间完全一致,但也存在着成本不同的特殊情况。大家可以在后文的“监控使用成本”章节来更为深入地了解AWS成本结构。
正常运行时间架构
如果大家误以为云计算永远不会发生停机等故障,请再仔细思考一番。虽然AWS家族中的一部分服务拥有非常出色的可靠性,而且AWS方面也提供大量功能以简化停机事故发生后的恢复工作,大家仍然需要将可靠性规划与工程技术机制作为部署流程中的重要组成部分。
举例来说,大家可能会在AWS所使用的底层Xen虚拟机管理程序当中发现严格漏洞,而且一部分AWS设备需要在补丁安装的过程中进行重启。此外,负责在后台处理各类任务的物理服务器有可能——或者说一定会发生故障。如果缺少内置自动化机制的支持,在AWS之上建立而成的网站方案可能出现意料之外的运行状态,甚至在服务器崩溃或者后端重启时导致业务不可用。
一般来讲,大家应当确保重要站点能够在同一区域内的多个可用区中正常运行。通常情况下,这要求我们从起步之初就将多可用区部署思路纳入数据库后端设计当中。在内部基础设施中部署更多数据库服务器肯定会带来更高使用成本,因此大家要选择多可用区数据库选项时也要做好承担更多支出的心理准备。
最典型的设置当中需要引入一套弹性负载均衡器(简称ELB),其作用在于将输入应用程序的流量分配到多个计算实例当中。与此同时,流量还会被自动从存在故障的实例处被转移到正常运行的实例当中,这相当于在特定可用区遭遇灾难性事故时将负载迁移至其它正常可用区。
#p#
别忘了安全性议题
AWS一直高度重视安全问题,对于一家只需要鼠标点击几下就能建立或者移除数百台服务器的供应商来说,关注安全自然也在意料之中。举例来说,一家拥有光明发展前景的初创企业很可能由于黑客入侵Amazon EC2控制面板而导致业务体系彻底崩溃——甚至整套基础设施都被完全移除。
为了实现更出色的管理安全水平,AWS方面建议客户为用户设定受到严格限制的权限内容,从而管理其负责范畴之内 的资源——而不能设置“root”用户并允许其进行无限制访问。正如典型Linux系统,用户可以被分配至多个组,而其它角色早可被创建并分配至至用户或者对应组。
AWS同时支持虚拟与基于硬件的MFA(即多因素验证)方案,上图所示为Gemalto安全令牌。
除此之外,AWS还提供多因素验证(简称MFA)方案,且同时具备硬件与虚拟选项。在硬件MFA方面,AWS支持来自第三方供应商Gemalto公司的安全令牌产品。再有,AWS还支持虚拟MFA应用,例如在Android、iPhone以及黑莓设备平台上的谷歌Authenticator,外加Android平台上专有的AWS Virtual MFA应用程序。
监控使用成本
最后,在云计算方面,大家听到的最多的可能其降低基础设施使用成本的能力。不过企业用户可能会逐渐发现,云服务的运营成本会随时间推移而不断增加,在某些特定情况下其短期成本甚至会高于内部部署方案。
为了帮助用户更为明确地了解自己的云部署成本,AWS设计一款以月为单位的计算工具,帮助用户以数字为基础了解自己所使用服务项目的部署成本。其中的评估指标包括磁盘及网络资源的使用水平。这能够帮助企业在无需针对特定可靠性或服务项目的前提下决定现有运营成本是否符合预期。
企业当然希望根据现有部署方案对使用成本进行优化,在这种情况下大家不妨根据现有资源使用水平购买“临时”或者“保留”计算实例。简而言之,前者允许企业以较低价格使用整体云环境下的闲置计算能力,而后者则允许企业客户预先登记及/或预先支付未来需要使用的资源成本。很明显,临时实例所调用的资源未必始终来自同区域。
大家可以预先登记最多三年的预期资源使用量,预先支付机制也同样支持最多一年周期,二者都能带来更为实惠的运营成本。
AWS自身还提供一套值得依赖的咨询服务,能够帮助企业用户调整AWS部署流程中的各方面项目,包括安全保障与运维成本优化。当然,要获得真正全面的顾问建议,大家需要购买付费支持计划。
在今天的文章中,我们仅仅涉及到了AWS所提供的全部可行性提示中的一小部分,但相信这已经足以帮助大家建立正确的云计算发展思路。如果想要选择AWS作为自身业务基础,首先要做的就是提出关于迈出下一步的正确问题。
原文标题:How to set up Amazon Web Services for your small business