aws 分区扩展

通常情况下，我们的aws默认根分区大小为8G ，是不够用的，因此需要扩展其大小，首先登陆到aws，选择EC2的服务器占用的存储卷，点击 *** 作--->修改卷，填写修改卷的大小，点击修改，卷的状态会变为in-use-optimizing,等待卷的状态变为in-use即可。
此时ssh登录到服务器，首先扩展根分区的大小，之后扩展文件系统的大小。
扩展根分区大小：
输入lsblk我们可以看到，根卷的大小为80G ，但是实际根分区只占有8个G,因此需要扩展根分区的大小。

扩展的命令为： sudo growpart /dev/xvda 1 ，注意设备和分区号之间有空格。

我们可以看到，/dev/xvda1的大小已经扩展到80G 。但是文件系统还没有扩展，可以通过 df -Th 命令查看。

此时，对于不同类型的文件系统要采用不同的扩展命令，如果是ext2、ext3 或 ext4 文件系统。要使用 sudo resize2fs /dev/xvda1 ,对于xfs文件系统的扩展命令为 sudo xfs_growfs /dev/xvda1 。我这里采用xfs文件系统的扩展命令。

可以看到根分区的大小已成功扩展到80G。

基础架构
AWS分布在全球12个区域里
每个区域对应着一个地理位置，里面含有多个Availability
Zones(可用区)。这些区域设置在北美，南美，欧洲，中东，非洲，亚太区。
每个AZ实质上是单个数据中心，尽管它们可由多个数据中心构建。
每个AZ有着独立的供电系统和互联网连接。
不同AZ之间以低延迟网络进行连接，这种快速网络可消除物理位置带来的速度影响。
每个区域含有至少两个AZ，共计32个AZs。
借助AZ可创建高可用性的程序架构。
AWS在全球还分布有53个偏远区域(Edge locations)
偏远区域的使用对象是CloudFront，这是Amazon的内容分发网络(CDN)和DNS服务器。
偏远区域的存在使得全球用户都可以享用低延迟网络而不论他们身在何处。建立区块服务(Block Services)
Amazon透过AWS创建了大量高可用和高容错的服务，具体的服务清单可点击这里查看。
缴纳一定的费用，你就可以在个人的应用中使用这些服务而不必为高可用性而忧心。
部分服务位于一个AZ中：CloudFront, Route 53, S3, DynamoDB, Elastic Load
Balancing, EFS, Lambda, SQS, SNS, SES, SWF。
即使是使用单个AZ的服务，其高可用架构也是足够强大的。
1个用户
在这个时候，开发者=用户。你的架构看起来是这样的：
运行单个实例，如t2micro。你可以为你的服务器选择不同的CPU，内存，存储设备和网络环境。
该服务器承载了全部web任务，如：web应用，数据库，管理器等。
使用AmazonRoute 53进行DNS管理。
为该实例附加一个Elastic IP地址。
那么随着用户数的增加，我们需要如何进行升级改造，直至能为千万用户提供优质的服务呢？强调文字
优化策略
采用多主机模式
尝试使用Amazon数据库服务，如Amazon RDS(关系数据库)，Amazon DynamoDB(NoSQL数据库)，Amazon Redshift。
逐步从SQL数据库转为NoSQL数据库，特别是数据量超过5TB，你的应用对低延迟敏感的时候。
使用Elastic Load Balancer(d性负载均衡器)，它可以对主机进行健康检测以确保网络的通畅，同时可以帮助实现网络的扩展。
垂直升级
需要更强的实例类型，例如c48xlarge或者m32xlarge。
停止使用当前的服务器，换用功能更强大的机器，如：244GB RAM，40核CPU。
某些Amazon服务提供了Provisined IOPS选项以便用户自行配置变更，这样一来用户可以使用类似DynamoDB的扩展服务。
类似上面的做法就叫做垂直升级。但其有个缺点，就是一旦机器出错，你的网站也会停止运作了。所以要尽量避免单个实例的做法。
自动扩展
如果你一直在为峰值负载而努力，如黑色星期五，那么其实是在浪费金钱。更好的解决方案
列表内容
是按需分配，这就是Auto Scaling(自动扩展)，在计算机群组中实现自动化的大小变更。
你可以为你的容量池定义最大值和最小值。
CloudWatch是一个管理服务，已内置到所有的Amazon应用中。
CloudWatch事件会触发扩展。
触发事件可以是CPU占用率，时间延迟，网速等等。
你也可以向CloudWatch导入自定义基线，按照你的意愿来触发扩展。
架构分解
使用SOA/微服务，使你的服务层组件化。
这样做的好处是单独的服务可以独立地进行扩展，从而大大增加了灵活性和可用性。
SOA是Amazon提供的重要架构组件。
避免重复劳动
把精力投入到能使你的业务与众不同的事情上。
Amazon提供了很多高容错的服务。例如，排队(SQS服务)，邮件，转码，搜索，数据库，监控等等。所以类似的服务都不必再次编写了。
用户数>千万+
当用户达到千万级别的时候，你考虑的策略应该是这样的：
多AZs模式
在不同层之间执行ELB(d性负载平衡)。除了web层，在应用层，数据层等层里也需要进行ELB。
能够自动扩展
使用面向服务的架构
缓存架构内和外的数据
使用Amazon S3和CloudFront。S3用于存储静态数据，如js，CSS，图像等，具有足够的扩展性。CloudFront可对数据进行缓存。
使用Amazon SES来进行邮件发送。
使用CloudWatch进行监控。
对数据写入执行如下的策略：
联结 – 根据功能划分不同的数据库。
分表 – 把一个数据集分解到多个主机上。
把部分功能放到其他类型的数据库上（NoSQL,graph等）。
不断优化你的应用和整个架构堆栈，针对瓶颈进行分析并找出解决方法。

使用stunnel命令创建到 redis 节点的 SSL 隧道。然后，您可以使用 redis-cli 连接到从隧道，以便从加密的 Redis 节点访问数据。具体步骤如下所示：

在aws上找台ec2服务器， SSH登陆服务器，安装stunnel
1、sudo yum -y install stunnel

注明：

使用netstat命令确认隧道已启动

/home/ec2-user/redis-stable/src/redis-cli -h localhost -p 6379

sudo pkill stunnel

6、到此我们stunnel隧道已做好，下面就是直接在Windows上可视化工具连接。
这里有一个坑，我刚开始使用RDM连接redis，可以连接，但是无法查看数据，经过多方尝试，更换可视化客户端后正常。

7、如下图所示，连接redis服务器，命令行可用，但是db0无法显示数据。

8、多次尝试后，更换可视化工具可正常，正常使用可视化工具：Another Redis Desktop Manager。可以正常查看redis各项信息及数据。

首先讲微软，微软做企业客户产品起家的，现在也主要是从企业客户那里挣钱吃饭。虽然公司不停地喊着转型，在消费产品领域不断加大投入。但是这个公司
深入到骨子的基因就是善于做企业级的产品。
这种基因贯穿微软从研发到运维到销售到支持的各个部门。那么什么是企业客户的需求？3个词可以概括：可靠可信可用。那么反过来大家想想目前公有云服务的主
要客户应该是谁？他们的核心需求是什么？所以微软做公有云的优势其实显而易见，错就错在没有早点开始做，浪费了先发优势。
1
企业级品质和面向企业客户：从数据中心建设，全球光纤网络到虚拟化技术（Hyper-V）到 *** 作系统（WinServer）再到运行云服务的各项基础软件
（SQL，IIS）全部是微软自己研发的成熟的产品，都有几年甚至几十年在企业环境中运行的历史，其稳定性和可靠性是毋庸置疑的。另外，安全性也会相应增
强，大家应该都忘不了今年把许多企业吓出翔的OpenSSL heartbleed漏洞和最近刚爆出来的Xen Hypervisor的漏洞。
2

公有云和私有云混搭（传说中的混合云）：关注微软云计算的筒子们应该都关注到了最近Satya在旧金山提到的那个“把Azure装进盒子里卖给企业”的产
品。微软内部已经开发这个产品很久了。简单地说，就是卖一个现成的类似的Azure私有云给你，你可以按照企业需要自己管理和使用。然后这个私有云，无论
从接口和体验上，都与Azure高度统一，可以向公有云无缝扩展。这对很多想“脚踩两只船”（混合云）的大企业的吸引力是无疑的。
亚马逊和谷歌目前还像还没听说加力在这块。
3
与微软固有的产品线无缝整合，个人觉得这是最NB的一点。自从老鲍临走之前提出了cloud
first的口号之后，几乎所有的微软产品线都在考虑跟云沾上边，免得哪天突然发现bugdet被砍了。最后的结果就是，现在几乎所有的产品都实现了与
Azure的整合。比如VS可以直接开发和部署云服务，比如SC可以直接管理Azure
VM，Office可以直接打开和保存云上的文档等等。有些产品甚至直接跳到Azure上变成SaaS/PaaS云服务，比如说AD现在有AAD，SQL
现在有SQL Azure等等。所以Azure很快就形成了一个从IaaS(VM, Network)到PaaS(Storage, SQL,
Media )到SaaS(Office 365, Machine Learning, VSOnline,
AAD)一套极为完整的云生态体系。这些产品本来就有很大的用户群体，现在这些用户都可以轻松地迁移到Azure上，这就是为什么Azure这几年都在飞
速地增长的重要原因。在这一点上，微软算是吸取了Windows Phone和Windows
RT失败的深刻教训，那就是要玩就跟你玩生态系统！这点Amazon和Google也只能干着急了。
4 最后一点也是最重要的一点，微软有钱（从在全球建设数据中心的速度上就能看出来，微软远超其他两家）！在这一点上，Google能有得一拼。因为到目前为止，公有云计算基本上还是拼烧钱的游戏。一旦价格战开始，Amazon就有点疼。
其次讲亚马逊。
1

首先作为市场老大和商业云计算名义上的先驱，亚马逊最大的优势还是在于先入为主。以EC2和S3形成的一系列生态圈和开发者，是亚马逊目前异常坚挺的壁
垒。另外，整体来讲，亚马逊在一些关键的服务和功能上，还是领先于微软和谷歌。举个例子来讲，AWS的存储服务按照用户的数据特性就提供3种不同的产品：
高读写的热数据有SSD storage,
普通读写的数据有S3，冷备份数据有Glacier。而微软最近刚刚才发布了基于SSD存储。Google更是只有一种存储产品。
2 亚马逊是从互联网公司起家的，这个从内到外也贯穿着互联网的基因和风格。这些体现他倾听和理解用户需求，快速迭代产品功能，以及非常接地气的各种推广活动上。 在这一点上，默默无闻的ms和高高在上的gg这应该多想amazon学习一下。
最后说说google和其他的云服务。
毫
无疑问，Google在分布式计算和分布式存储方面的技术一定是非常牛的，如果Google称第二，估计没人敢称第一，因为他们开发和运维着世界上最大的
在线服务。Goolge在2003年的时候公布了一些分布式存储和分布式计算的细节，成为很多云计算框架和服务的蓝本。但是，google自从发布了
APP
engine之后，一直在商业云计算尤其是火热的IaaS市场里不温不火，以至于在全球商业云计算市场中远远落后于另外两家巨头。但是从去年开
始，Google已经开始高调发力了。
Softlayer, 还有一些国内的云计算厂商比如阿里云，在全球来看算是第二梯队的厂商，他们的优势应该是本地化运营和渠道优势吧。比如说，阿里云在国内接受了万网的一些客户，同时在中小企业和创业团队中的服务商很有优势。

---