比特客户端
您的位置：
详解大数据
详解大数据
详解大数据
详解大数据
AWS Auto Scaling：云服务成本与性能平衡利器
关键字：AWS
　　基于即付即得(pay-as-you-go)的模型有助于开发人员和架构师设计出能够一直运行于最佳资源分配下的应用程序。给过高的配置来满足业务需要意味着花费太多冤枉钱，这个错误的另一个极端则更糟糕，即给服务器过低的配置导致应用程序的性能不足。而应用程序要求的变化使得对的选择变得更加困难，因为最佳的资源组合不是一成不变的。
　　使用AWS服务来应对这些变化的一种方法是创建一个负载均衡服务器集群，然后根据需要添加或删除服务器。你可以自己管理这样一种集群，除此之外,你还可以尝试AWS Auto Scaling服务。该服务在避免过度配置的条件下保持足够的性能，同时也能够减少一些管理费用。该服务要达到的最佳应用场景是工作负载变化显著变化时，AWS Auto Scaling能够轻松地跨多个服务器分配负载。
　　AWS Auto Scaling 使用CloudWatch(亚马逊提供的一种监控工具)来提供所需的性能数据，完成伸缩服务建议。每隔五分钟，CloudWatch都将从服务器和其他AWS资源处，免费地收集性能统计数据，包括CPU使用率、使用情况和数据传输情况等。(额外付费的话将可获得每分钟一次的性能指标收集服务。)系统管理员可根据这些测量信息规定添加或删除服务器的配置策略。例如，一项配置策略指示当CPU平均利用率超过70%时，将启动一个额外的虚拟实例。
　　通过实现自动伸缩组协助制定配置策略
　　使用AWS Auto Scaling服务的第一步是实现一个自动伸缩组，即在逻辑上统一管理的一组亚马逊弹性计算云(EC2)实例。每一个组均定了最小和最大实例数，而实际数值则由基于CloudWatch的测量值做出的配置策略来决定。当需要手动干预时，通过AWS提供的ExecutePolicy命令行，系统管理员便可以无需等待触发条件，直接执行一项策略。
　　通过自动伸缩组的应用，在维护应用程序性能和开销的许多相关工作中得到了帮助。
　　自动伸缩组能够跨越可用性区域(一种能够支撑应用程序高可用性要求的特性)提供服务。这些可用性区域处于AWS 范围内，例如，美国东部(北维吉尼亚)或欧盟地区(爱尔兰)，通过不同的基础架构隔离故障实例与正常实例。如果在某个可用性区域中发生了故障，AWS Auto Scaling将在同一个地理区域内的某个功能区启动一个新的实例。
　　自动伸缩组能够通过负载均衡器配置集群内服务器间的工作负载。亚马逊的弹性负载均衡服务提供了一个到你的应用程序的所有流量的单点访问。当使用负载均衡器时，可以引用负载均衡测量指标(比如请求等待时间)以及EC2实例测量指标来制定自动伸缩策略。
　　除了响应变化的负载，Auto Scaling还支持其他伸缩选项，包括持续确保当前实例的性能、手动伸缩以及基于排程的伸缩。
　　应对AWS Auto Scaling的潜在问题
　　完成一项自动伸缩策略的指定动作需要花费一定的时间，然而，AWS在一次触发后，实现了一个冷却周期，用于防止当对触发器最初的响应还在继续的时候，执行了对触发器第二次响应所引起的一系列事件。冷却周期始于执行策略动作。
　　针对和一些应用程序服务器而言，当应用程序负载可以分布在多个服务器之上时，自动伸缩不无裨益。某些系统(如系统)可以配置运行于集群中，但其中存在诸多缺点：商业版关系型可能通过收取额外授权费用来提供集群支持，这些授权费甚至会超过因在不同数量的小型服务器运行数据库而拒绝一台大型服务器所节省下来的费用。此外还要考虑管理数据库服务器集群与管理单个服务器的不同开销。
[ 责任编辑：李桢君 ]
为更好推动开放架构发展，打造开…
甲骨文的云战略已经完成第一阶段…
软件信息化周刊
比特软件信息化周刊提供以数据库、操作系统和管理软件为重点的全面软件信息化产业热点、应用方案推荐、实用技巧分享等。以最新的软件资讯，最新的软件技巧，最新的软件与服务业内动态来为IT用户找到软捷径。
商务办公周刊
比特商务周刊是一个及行业资讯、深度分析、企业导购等为一体的综合性周刊。其中，与中国计量科学研究院合力打造的比特实验室可以为商业用户提供最权威的采购指南。是企业用户不可缺少的智选周刊！
比特网络周刊向企业网管员以及网络技术和产品使用者提供关于网络产业动态、技术热点、组网、建网、网络管理、网络运维等最新技术和实用技巧，帮助网管答疑解惑，成为网管好帮手。
服务器周刊
比特服务器周刊作为比特网的重点频道之一，主要关注x86服务器，RISC架构服务器以及高性能计算机行业的产品及发展动态。通过最独到的编辑观点和业界动态分析，让您第一时间了解服务器行业的趋势。
比特存储周刊长期以来，为读者提供企业存储领域高质量的原创内容，及时、全面的资讯、技术、方案以及案例文章，力求成为业界领先的存储媒体。比特存储周刊始终致力于用户的企业信息化建设、存储业务、数据保护与容灾构建以及数据管理部署等方面服务。
比特安全周刊通过专业的信息安全内容建设，为企业级用户打造最具商业价值的信息沟通平台，并为安全厂商提供多层面、多维度的媒体宣传手段。与其他同类网站信息安全内容相比，比特安全周刊运作模式更加独立，对信息安全界的动态新闻更新更快。
新闻中心热点推荐
新闻中心以独特视角精选一周内最具影响力的行业重大事件或圈内精彩故事，为企业级用户打造重点突出，可读性强，商业价值高的信息共享平台；同时为互联网、IT业界及通信厂商提供一条精准快捷，渗透力强，覆盖面广的媒体传播途径。
云计算周刊
比特云计算周刊关注云计算产业热点技术应用与趋势发展，全方位报道云计算领域最新动态。为用户与企业架设起沟通交流平台。包括IaaS、PaaS、SaaS各种不同的服务类型以及相关的安全与管理内容介绍。
CIO俱乐部周刊
比特CIO俱乐部周刊以大量高端CIO沙龙或专题研讨会以及对明星CIO的深入采访为依托，汇聚中国500强CIO的集体智慧。旨为中国杰出的CIO提供一个良好的互融互通 、促进交流的平台，并持续提供丰富的资讯和服务，探讨信息化建设，推动中国信息化发展引领CIO未来职业发展。
IT专家新闻邮件长期以来，以定向、分众、整合的商业模式，为企业IT专业人士以及IT系统采购决策者提供高质量的原创内容，包括IT新闻、评论、专家答疑、技巧和白皮书。此外，IT专家网还为读者提供包括咨询、社区、论坛、线下会议、读者沙龙等多种服务。
X周刊是一份IT人的技术娱乐周刊，给用户实时传递I最新T资讯、IT段子、技术技巧、畅销书籍，同时用户还能参与我们推荐的互动游戏，给广大的IT技术人士忙碌工作之余带来轻松休闲一刻。
微信扫一扫
关注Chinabyte软件与服务//
AWS Auto Scaling：云服务成本与性能平衡利器
　　基于即付即得(pay-as-you-go)的云计算模型有助于开发人员和架构师设计出能够一直运行于最佳资源分配下的应用程序。给服务器过高的配置来满足业务需要意味着花费太多冤枉钱，这个错误的另一个极端则更糟糕，即给服务器过低的配置导致应用程序的性能不足。而应用程序要求的变化使得对服务器配置的选择变得更加困难，因为最佳的资源组合不是一成不变的。
　　使用AWS服务来应对这些变化的一种方法是创建一个负载均衡服务器集群，然后根据需要添加或删除服务器。你可以自己管理这样一种集群，除此之外,你还可以尝试AWS Auto Scaling服务。该服务在避免过度配置的条件下保持足够的性能，同时也能够减少一些管理费用。该服务要达到的最佳应用场景是工作负载变化显著变化时，AWS Auto Scaling能够轻松地跨多个服务器分配负载。
　　AWS Auto Scaling 使用CloudWatch(亚马逊提供的一种监控工具)来提供所需的性能数据，完成伸缩服务建议。每隔五分钟，CloudWatch都将从服务器和其他AWS资源处，免费地收集性能统计数据，包括CPU使用率、磁盘使用情况和数据传输情况等。(额外付费的话将可获得每分钟一次的性能指标收集服务。)系统管理员可根据这些测量信息规定添加或删除服务器的配置策略。例如，一项配置策略指示当CPU平均利用率超过70%时，将启动一个额外的虚拟实例。
　　通过实现自动伸缩组协助制定配置策略
　　使用AWS Auto Scaling服务的第一步是实现一个自动伸缩组，即在逻辑上统一管理的一组亚马逊弹性计算云(EC2)实例。每一个组均被指定了最小和最大实例数，而实际数值则由基于CloudWatch的测量值做出的配置策略来决定。当需要手动干预时，通过AWS提供的ExecutePolicy命令行，系统管理员便可以无需等待触发条件，直接执行一项策略。
　　通过自动伸缩组的应用，企业在维护应用程序性能和开销的许多相关工作中得到了帮助。
　　自动伸缩组能够跨越可用性区域(一种能够支撑应用程序高可用性要求的特性)提供服务。这些可用性区域处于AWS 范围内，例如，美国东部(北维吉尼亚)或欧盟地区(爱尔兰)，通过不同的基础架构隔离故障实例与正常实例。如果在某个可用性区域中发生了故障，AWS Auto Scaling将在同一个地理区域内的某个功能区启动一个新的实例。
　　自动伸缩组能够通过负载均衡器配置集群内服务器间的工作负载。亚马逊的弹性负载均衡服务提供了一个到你的应用程序的所有流量的单点访问。当使用负载均衡器时，可以引用负载均衡测量指标(比如请求等待时间)以及EC2实例测量指标来制定自动伸缩策略。
　　除了响应变化的负载，Auto Scaling还支持其他伸缩选项，包括持续确保当前实例的性能、手动伸缩以及基于排程的伸缩。
　　应对AWS Auto Scaling的潜在问题
　　完成一项自动伸缩策略的指定动作需要花费一定的时间，然而，AWS在一次触发后，实现了一个冷却周期，用于防止当对触发器最初的响应还在继续的时候，执行了对触发器第二次响应所引起的一系列事件。冷却周期始于执行策略动作。
　　针对Web服务器和一些应用程序服务器而言，当应用程序负载可以分布在多个服务器之上时，自动伸缩不无裨益。某些系统(如关系型数据库系统)可以配置运行于集群中，但其中存在诸多缺点：商业版关系型数据库可能通过收取额外授权费用来提供集群支持，这些授权费甚至会超过因在不同数量的小型服务器运行数据库而拒绝一台大型服务器所节省下来的费用。此外还要考虑管理数据库服务器集群与管理单个服务器的不同开销。
关键词：X86服务器
责任编辑：郑亮
All Rights Reserved, Copyright , .cn渝ICP证B2-号 如有意见请与我们联系 powered by 天极内容管理平台CMS4i
京公网安备84号AWS Auto Scaling：云服务成本与性能平衡利器
日期：作者：
&&&&&&&&&&&&
【TechTarget中国原创】 基于即付即得（pay-as-you-go）的云计算模型有助于开发人员和架构师设计出能够一直运行于最佳资源分配下的应用程序。给服务器过高的配置来满足业务需要意味着花费太多冤枉钱，这个错误的另一个极端则更糟糕，即给服务器过低的配置导致应用程序的性能不足。而应用程序要求的变化使得对服务器配置的选择变得更加困难，因为最佳的资源组合不是一成不变的。 使用AWS服务来应对这些变化的一种方法是创建一个负载均衡服务器集群，然后根据需要添加或删除服务器。你可以自己管理这样一种集群，除此之外,你还可以尝试AWS Auto Scaling服务。该服务在避免过度配置的条件下保持足够的性能，同时也能够减少一些管理费用。该服务要达到的最佳应用场景是工作负载变化显著变化时，AWS Auto Scaling能够轻松地跨多个服务器分配负载。 AWS Auto Scaling 使用CloudWatch（亚马逊提供的一种监控工具）来提供所需的性能数据，完成伸缩服务建议。每隔五分钟，CloudWatch都将从服务器和其他AWS资源处，免费地收集性能统计数据，包括CPU使用率、磁盘使用情况和数据传输情况等。（额外付费的话将可获得每分钟一次的性能指标收集服务。）系统管理员可根据这些测量信息规定添加或删除服务器的配置策略。例如，一项配置策略指示当CPU平均利用率超过70%时，将启动一个额外的虚拟实例。
我们一直都在努力坚持原创.......请不要一声不吭，就悄悄拿走。
我原创，你原创，我们的内容世界才会更加精彩！
【所有原创内容版权均属TechTarget，欢迎大家转发分享。但未经授权，严禁任何媒体（平面媒体、网络媒体、自媒体等）以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
TechTarget中国
查看更多评论
敬请读者发表评论，本站保留删除与本文无关和不雅评论的权力。
AWS Auto Scaling：云服务成本与性能平衡利器
Dan Sullivan是一名作家、系统架构师和顾问，拥有超过20年关于先进的分析、系统架构、数据库设计、企业安全、商业智能的IT从业经验。他的从业范围广泛，包括金融服务业、制造业、医药、软件开发、政府、零售、天然气和石油生产、发电、生命科学和教育。
AWS Auto Scaling组不断重复启动，杀掉实例会让一家企业增加许多额外的支出。严格管理的配置可以防止这个问题。
在AWS、Azure以及谷歌中，公共云计算成本都是一笔较大的负担，因此企业用户应当把AWS资源管理起来以求在最小的费用支出基础上获得最大的收益。
我们正在探讨迁移专有数据库（非PII）到AWS云的风险预测。相比较传统的数据库迁移，哪些额外的安全措施应该被考虑在内？是否应该应用额外的AWS安全机制？
北京的第一场春雨已经降临，雾霾的城市却并未因此而缓解饥渴。三月份是一个一切都蓬勃发展的季节，也是一个播种的季节，2014年注定是一个云计算分外忙碌的年度，接下来让我们看看这个月有哪些值得关注的文章。
云计算应用落地是一个很漫长的过程。在部署云计算之前，用户必须认识各个平台供应商及其云平台，然后根据自身架构选择合适的云平台投入运营。
云服务帮助企业解决了构建IT基础设施和应用的难题，但是企业如何提高云服务的性能？如何高效地使用云服务？本手册介绍云服务性能和标准以及评估云服务的相关技巧法则。
虽然云计算发展的春天已经来临，但是众多企业仍然希望保持对IT环境和物理资源的控制。通常情况下，法律或法规会阻止企业实施从数据中心到公共云计算的转变。这就成全了私有云计算，它允许企业在本地管理硬件，同时又允许最终用户远程访问基础设施的下一个逻辑步骤。尽管每个IT环境都是独一无二的，但是对你的私有云计算项目实现从规划到投产有很多可供借鉴的最佳实践案例，其中包括选择正确的管理程序、软硬件以及合适的广域网和宽带技术。在这本技术手册中，我们将会关注企业私有云选型以及如何落地。
应用集成从1980年代中期就已经成为企业软件的痛点，也是那个时候我第一次开始做IT报道。同样的老问题让不同的软件共存，大部分是因为业主权益要比开放标准高。
TechTarget
企业级IT网站群
TechTarget中国 版权所有
All Rights Reserved, Copyright
TechTarget中国 版权所有
All Rights Reserved, Copyright
【TechTarget中国原创】 基于即付即得（pay-as-you-go）的云计算模型有助于开发人员和架构师设计出能够一直运行于最佳资源分配下的应用程序。给服务器过高的配置来满足业务需要意味着花费太多冤枉钱，这个错误的另一个极端则更糟糕，即给服务器过低的配置导致应用程序的性能不足。而应用程序要求的变化使得对服务器配置的选择变得更加困难，因为最佳的资源组合不是一成不变的。 使用AWS服务来应对这些变化的一种方法是创建一个负载均衡服务器集群，然后根据需要添加或删除服务器。你可以自己管理这样一种集群，除此之外,你还可以尝试AWS Auto Scaling服务。该服务在避免过度配置的条件下保持足够的性能，同时也能够减少一些管理费用。该服务要达到的最佳应用场景是工作负载变化显著变化时，AWS Auto Scaling能够轻松地跨多个服务器分配负载。 AWS Auto Scaling 使用CloudWatch（亚马逊提供的一种监控工具）来提供所需的性能数据，完成伸缩服务建议。每隔五分钟，CloudWatch都将从服务器和其他AWS资源处，免费地收集性能统计数据，包括CPU使用率、磁盘使用情况和数据传输情况等。（额外付费的话将可获得每分钟一次的性能指标收集服务。）系统管理员可根据这些测量信息规定添加或删除服务器的配置策略。例如，一项配置策略指示当CPU平均利用率超过70%时，将启动一个额外的虚拟实例。 通过实现自动伸缩组协助制定配置策略 使用AWS Auto Scaling服务的第一步是实现一个自动伸缩组，即在逻辑上统一管理的一组亚马逊弹性计算云（EC2）实例。每一个组均被指定了最小和最大实例数，而实际数值则由基于CloudWatch的测量值做出的配置策略来决定。当需要手动干预时，通过AWS提供的ExecutePolicy命令行，系统管理员便可以无需等待触发条件，直接执行一项策略。 通过自动伸缩组的应用，企业在维护应用程序性能和开销的许多相关工作中得到了帮助。 自动伸缩组能够跨越可用性区域（一种能够支撑应用程序高可用性要求的特性）提供服务。这些可用性区域处于AWS 范围内，例如，美国东部（北维吉尼亚）或欧盟地区（爱尔兰），通过不同的基础架构隔离故障实例与正常实例。如果在某个可用性区域中发生了故障，AWS Auto Scaling将在同一个地理区域内的某个功能区启动一个新的实例。 自动伸缩组能够通过负载均衡器配置集群内服务器间的工作负载。亚马逊的弹性负载均衡服务提供了一个到你的应用程序的所有流量的单点访问。当使用负载均衡器时，可以引用负载均衡测量指标（比如请求等待时间）以及EC2实例测量指标来制定自动伸缩策略。 除了响应变化的负载，Auto Scaling还支持其他伸缩选项，包括持续确保当前实例的性能、手动伸缩以及基于排程的伸缩。 应对AWS Auto Scaling的潜在问题 完成一项自动伸缩策略的指定动作需要花费一定的时间，然而，AWS在一次触发后，实现了一个冷却周期，用于防止当对触发器最初的响应还在继续的时候，执行了对触发器第二次响应所引起的一系列事件。冷却周期始于执行策略动作。 针对Web服务器和一些应用程序服务器而言，当应用程序负载可以分布在多个服务器之上时，自动伸缩不无裨益。某些系统（如关系型数据库系统）可以配置运行于集群中，但其中存在诸多缺点：商业版关系型数据库可能通过收取额外授权费用来提供集群支持，这些授权费甚至会超过因在不同数量的小型服务器运行数据库而拒绝一台大型服务器所节省下来的费用。此外还要考虑管理数据库服务器集群与管理单个服务器的不同开销。笔者所属项目从零开始接触AWS，到目前在7个AWS地区部署上线，运行维护将近4年的时间，着重就这几个方面来展开：AWS的故障自动伸缩规则DDoS防护小建议1AWS的故障从我们2011年接触AWS至今，比较大一点的故障多集中于2012年，小故障每年零零星星还会有一些，总的来说AWS的稳定性和可靠性是越来越好。这边先简单介绍一下，AWS每一个区域（Region）都会有多个可用区（Availability Zone，简称AZ），可用区之间互相独立，不受其他可用区故障的影响。我们遇到过一个可用区（AZ）故障，最初的表象是网络时断时续，API Error Rate增加，AWS论坛里面也很有很多人报这个问题，当时没有回应。接下来，网络开始大面积中断，直到整个可用区的EC2服务处于几乎不可用的状态，AWS网站开始告知可用区故障的信息。再往下，该地区的AWS Management Console也基本刷不出内容。我们自己的监控系统，产生大量的告警，且持续了一个多小时，当时也吓出一身冷汗。因为无法进行直接的人工干预–AWS API直接返回503服务不可用。另外，AWS文档中提到的关于可用区挂掉后，新的机器会在另一个区自动创建的功能，似乎当时也没有起效。不过，好在我们的机器都是多可用区部署，除个别非关键组件单点，以及AWS API暂时不可用外，另一个可用区的网络并没有受到影响，对外服务也没有受到干扰。这个事件过后，我们开始反省，如果再发生要怎么办？（后来还真发生了）保持多可用区部署且无状态，避免单点服务，增加更细的监控点（比如对所使用的AWS服务本身）。ELB要打开Cross-Zone Balancing功能，按实际机器数量来均分流量，默认是按可用区均分流量。增加Fault Tolerance测试，类似Netflix Chaos Monkey的做法，评估我们所使用的每个AWS服务故障时，对服务可能产生的影响。跨地区的切换，比如：东京不可用，就把用户流量切到新加坡。购买AWS Support Plan，解决AWS故障时信息不透明且无人可帮忙的困境。零星小故障总结：定时事件，虽然官方不叫故障，属于我个人意见。有些底层的硬件存在故障或者需要更新，AWS会提前通知，到时间，通常情况下机器会被停掉重启。比较烦人的点就是冷不丁就冒出来了，通常都必须要去关注，当然不同的事件级别不同，出现时还是小心为好，找好维护时间窗，早点解决。有时候机器会被意外关掉，重启或者短暂网络故障，通常都不会有通知，而此时AutoScaling健康检查也相应失效。这种问题现在变得越来越少，主要靠监控发现，然后找AWS Support一起跟踪确认原因。如果使用DNS来帮助服务发现，就要小心Route53的API调用限制，因为Route53是全局服务，API调用数量的计算按一定时间内，所有地区调用的总和。这个本质上不算故障。 2自动伸缩自动伸缩（AutoScaling）可以认为是AWS的核心功能，可根据用户的业务需求和策略，自动调整其弹性计算资源。可用性和稳定性是通过定时健康状况检查和自动替换机器来做到的，包括EC2本身的健壮检查、使用ELB的健康监控，甚至自定义的监控通过API反馈给AutoScaling服务。伸缩规则分为两种：简单规则和步进规则。a. 简单规则，只根据一条规则增减容量，比如当平均CPU超过70%，增加两台机器。Cloud Watch会去自动监控这个指标，达到时就会告警，触发伸缩行为。这边要注意的是伸缩行为的发生必须等待其他伸缩行为完成，再响应告警。其中，增减的数量可以是定值也可以是百分比，同样Cloud Watch中监控到的数据，也可是通过API自定义灌入的。b. 步进规则，早先AWS并不支持，它包含一组规则。比如CPU在40%-50%时加一台机器，50%-70%加两台，70%以上加四台等等。此时，若已有伸缩行为发生，该规则还会继续响应告警，中间会有一个预热时间，时间不到，这个机器的指标都不会计入。和简单规则相比，这种规则的伸缩行为无锁，且持续统计指标，及时触发，推荐使用。关掉的机器不能做特定选择，但会有一些模糊的规则：运行时间最久的，隶属的伸缩规则最老的，接近一个小时的开机时间等等。对于是事先准备预编译好的AMI还是通过配置管理工具现场安装，对预热时间比较敏感的服务，推荐是前者。介绍完AWS中的自动伸缩服务，引出一个关键问题就是如何设置一个合理的规则，来比较精细地平衡成本和负载。这些都需要通过大量的测试来做权衡判断。设计伸缩规则，需要注意的地方是：这是一整个系统的调优过程，涉及到的参数，可能不仅仅是规则本身，比如，使用ELB的，还要考虑到相关的性能参数。这个规则可能会随程序的变革而变化，最好做到自动化。加机器要早，减机器要慢。负载开始增加时早作打算，因为中间有可能会产生新机器启动失败等问题，另外算上机器启动时间和服务到位的时间，早打算可以避免容量跟不上的问题；减机器时，要慢慢来，稳稳地进行。否则，一方面避免连接被硬生生掐断，另一方面由于减机器过快，而负载仍在，导致又要增加机器，这使得伸缩行为太过频繁，成本和稳定性会受到影响。采集机器的CPU数据，尽量使用Cloud Watch的，本机采集的数据不一定准确。应用本身需要记录足够的性能数据，写入日志，方便后期数据整理。如果有条件，可以尝试建立一个简单的数据模型来实际分析。3DDoS防护小建议这张图描述的是2015年第二季度AWS上有关DDoS的情况。一个DDoS攻击大小是1.04Gbps，大于10Gbps的攻击持续时间大约39分钟。图片中展示了AWS防范DDoS的方式，目前是Traffic Shaping，然后通过优先级来标识，如果判断是可能的攻击，就减慢它的速度。所以这边的建议是：利用ELB、Route53、Cloudfront（CDN）等已经具有防范DDoS功能的服务。将机器置于VPC中，设置合理的security group（防火墙），避免直接对外服务。针对应用层的攻击，则需要WAF来帮忙。这是一种AWS推荐的保护方式。最外层Cloudfront（CDN）和ELB，中间设置WAF，内层ELB，最后到应用部分。4Q&AQ：请问您觉得AWS和国内的云厂商相比，最大的优势是什么？A：从全球的角度来看，根据Gartner Report，是最领先的云服务。对于功能而言，AWS的服务多，质量上乘。对于业务需求在海外的，AWS更为重要。有些国内的云服务，基本上都是模仿着AWS起来的。Q： 防DDoS架构都需要自己搭建，AWS没有提供外层包装好的服务么？A：AWS内置的服务中已经提供了防范DDoS的能力，大多数情况下都够用，只是针对应用层的攻击，需要额外的服务。另外有很多安全厂商和AWS有合作，在AWS Market可以得到相应的安全服务。Q：你们用过ECS服务吗，功能上能否满足你们的应用需求？A：我们目前正在尝试采用ECS的方式来部署我们的服务，10月份的reInvent大会发布了Private Registry还有ecs-cli等一些工具，会使ECS更易使用。Q：前端放不同az还好说，后端数据库不同az怎么搞？A：数据库如果是自己在EC2上部署的话，比如我们使用的Cassandra，多台同样可以采用不同AZ，至于AWS本身的数据库服务RDS、Aurora、DynamoDB，里面有一个multi-AZ的功能。Q：另外目前很多公司都采用了云服务，很多运维同学比较关注的一个问题是会对运维成员带来了一定的影响，因为很多工作使用云服务就可以解决。一种观点是，上云，是运维人员的一个机会，因为使用云服务在某个方面来说，对运维人员的要求又提高了。目前熟悉AWS的运维人员并不好招。请问，您是怎么想的？A：这个问题，我自己也深有体会，Docker会这么火，里面也有这一层关系。Q：自动伸缩服务对于用户这边需要做哪些准备，如何保证代码持续更新，自动伸缩也是可用的，就是我怎样信任自动扩容出的机器？A：主要还得要求机器中的服务实现无状态，信任是建立在测试和监控的基础上。代码持续更新是另一个问题，持续发布的问题，这个现有的解决方案也蛮多的，可以线下讨论。Q：亚马逊云的故障率大概有多少，企业级应用的价格是否可以接受？A：目前根据我们使用的服务来看，故障率不高，稳定性和质量都蛮高的，剩下的都是一些小问题，2012年的时候曾有5个大问题（AWS专门解释原因的）。对于价格可能要具体问题具体看，对于我们而言，也做企业级应用，7个地区的部署，还是能接受的。Q：请问有没有部署将企业自己数据中心和AWS上服务互联，推荐方式是？A：公司里其他部门是有的，通过VPN的方式更安全。Q：请问ECS是否只有提供CD、CO、CI部分是否只能是用户自己定制和对接，还有预计ECS什么时候会在中国站点发布呢？A：AWS本身有提供code deploy、code pipeline、code commit持续发布的服务，可以和ECS一起使用，新发布的Private Registry也会对ECS的CI/CD带来帮助。中国站点的情况，不了解。Q：请问老师是否知道目前亚马逊在国内数据中心部署进展怎样？A：我们没有使用，所以具体的细节不太了解。似乎是有限开放，之前去reInvent开会，有一个中国专场，很多国内的公司都在使用了。Q：你们有考虑过灰度发布吗，AWS上对此是否有相应支持？A：有在使用，粒度现在还比较粗一点。一方面需要依靠应用程序本身，可以做到配置管理。AWS的支持，还是需要通过架构设计来做到，比如Router53支持带权值的DNS，另外还有今年发布的API Gateway也可以拿来帮忙。Q：目前AWS的一个趋势是推广基于事件的服务，就是逐步弱化服务器的概念，根据事件进行相关服务，这也是领先其它云厂商的一个方面，请问针对这一点，您是怎么想的？A：本来我也想聊聊lambda这个服务，考虑到时间的问题，没有讨论到。这确实是一个蛮好的想法。我了解的信息是，欧洲、北美有蛮多的公司采用了这种无服务器的方式，基本上不用自己来管理EC2机器，做好监控就可以。好处就是快，坏处就是和AWS耦合太紧。@Container容器技术大会将于日在北京举行，讲师正在确认中，爱奇艺、微博、腾讯、去哪儿网、美团云、京东、蘑菇街、惠普、暴走漫画等知名公司的负责人将分享他们的容器应用案例。欢迎感兴趣的同学报名，现在报名只需要100元。关于大会更多信息请点击左下角阅读原文链接查看。　
　文章为作者独立观点，不代表微头条立场
的最新文章
本文比较了几种 Kubernetes 联网方案，包括 Flannel（aws-vpc | host-gw | vxlan）和 IPvlan 。目前建议选择 Flannel + host-gw 方案，没有特别依赖，性能也够用。文章讨论了容器的持久化存储的问题。从持久化的定义到持久化的理解，并且对目前容器持久化的三种方案进行了回顾。持久化存储对于容器来说是否真的适合？本文作者主要围绕十二要素设计模式及容器架构方面对这一话题发表了自己的见解。本文主要介绍了Google GKE和Amazon ESC两个产品在实现自动收缩、冗余性和互操作性上的不同之处。这篇博客讨论了最近几年调度架构如何演进，为什么会这样。2016 年 1 月 10 日，数人云举办了 “Hold 住高并发，唯架构与运维不可辜负” 的主题沙龙，当当Docker的Swarm容器编排系统超越Google的Kubernetes了？最近的一个基准测试如是说，但从全局角度而言，情况要复杂得多。微博数据库优化经验。本文引用了多份关于容器的第三方调查报告。通过这些报告的结论可以清晰地勾勒出目前容器领域的发展状况。这次分享主要是讲如何充分利用Docker技术实现代码到线上环境的部署，以及在使用Docker中遇到的问题和困扰。Linux容器世界核心冲突之一：systemd与Docker守护进程。北京时间3月4日，Docker公司宣布收购Conductant公司，DockOne社区第一时间对官方博客进行了全文翻译。一篇介绍Docker的文章，还有实践案例。不懂Docker的同学，看这一篇就够了。文章讨论部署微服务的策略。本文介绍了微容器的概念和好处以及构建微镜像的基本原理。云计算作为一种服务和应用的业务模式，很难讲会被颠覆，但容器技术的确是云计算的game changer，它改变了我们思考云计算的视角，是云计算的reinventor。本文是CoreOS近期对Kubernetes扩容性的一些针对性试验、检测和研究，分析并且得出了对Kubernetes集群部署和pod吞吐量等Kubernetes集群性能问题、扩容性问题上一系列的尝试和见解。Docker公司宣布Docker Datacenter（简称DDC）正式发布，这套可集成的端到端平台设计用于高效地将应用程序开发和管理工作由内部数据中心迁移至云环境下。不可变基础设施（Immutable Infrastructure）是由Chad Fowler于2013年提出的一个很有的预见性的构想 ，其核心思想为任何基础设施的实例一旦创建之后变成为只读状态，如需要修改和升级，则使用新的实例进行替换。最近发现Linux内核bug，如果在自己环境中使用容器，强烈建议打上此补丁，或者等发布后，部署已经打上补丁的核心版本。目前能够以规模化方式运行微服务，从而解决实际问题的企业中，Twitter是典型的代表。Docker技术在Ruby社区是有影响力的，但是，有一些同学尚未注意到这个技术，或者了解过后认为它不是很重要，文章讨论了Docker对Ruby系技术的帮助。文章解释如何基于Docker搭建一套轻量级的私有构建环境并及集成到持续集成系统中。ShareThis 是一家提供社会化分享技术的初创企业，成立于 2007年。最近有消息说Docker准备使用Alpine Linux替代之前的Ubuntu做为官方默认的宿主环境（基础镜像）。鉴于还没有用Docker创建本地开发环境的先例，Jeff Nickoloff开创了一个先例，相信大家也可以。本文介绍了VMware最近宣布的两项容器解决方案，分别是整合了vSphere的容器技术（vSphere Integrated Containers，简称vIC）和Photon平台，并与现有方案进行了对比。Rkt诞生于2014年12月，是与Docker类似的另一款容器引擎，CoreOS强调Rkt更专注于解决安全、兼容、执行效率等方面的问题。北京时间2月5日，Rkt 1.0正式发布。DockOne社区第一时间全文翻译了官方新闻。随着Hadoop成为大数据的事实标准，Hadoop的生态也在不断完善，环境搭建的复杂性，给开发和测试带来了不便。如何用Docker来降低Hadoop开发中的复杂性，本文中Crayon带来了他们的方案。关于大会@Container大会是由国内容器社区DockOne组织的专为一线开发者和运维工程师设计的顶级容器本文的作者通过自己在CentOS上使用Docker比在Ubuntu上性能缓慢的体验差异，决定转向在Ubuntu上使用Docker。本文从一个实践者的角度，首先介绍了分布式系统的一些理论结果，例如 FLP 不可能性和 CAP 定理等；然后介绍了构建实际分布式系统最重要的一个原则：端到端；最后讨论了实际系统经常用到的协调服务。本文讨论如何通过将博客Docker化来上手Docker。本文介绍了容器和Kubernetes的底层概念，以及它们如何给应用开发提供了新的模式。作者通过实践，从集群构建、基础服务配置、部署、服务发现、持久化存储、端口管理等等多方面详细地对比了Kubernetes和ECS的优缺点，非常的全面，值得一读。@Container大会是由国内容器社区DockOne组织的专为一线开发者和运维工程师设计的顶级容器技术会议为开阔技术人眼界，促进技术人职业成长。DockOne在此诚意推荐8个2016年最值得关注的IT公众号。授人以本文是使用微服务创建应用系列的第五篇文章。本篇中，我们从另外一个角度研究一下微服务架构带来的分布式数据管理问题。本文将会简单介绍Kubernetes的核心概念。因为这些定义可以在Kubernetes的文档中找到，所以文章目前容器的双联是一个难点，必须手动配置。这篇文章介绍了实现双联的三种方法，对想玩容器的开发者来说有一定的帮助作用。DockOne.io成立于2014年，是国内最大的容器社区。我们关注Docker、Mesos、CoreOS、dockerone热门文章最新文章dockerone