Tag: 计算

1. 高性能计算的应用场景 科学家、工程师及科研者等经常需要使用大规模高性能计算集群（HPC）来解决计算密集或存储密集型计算的问题，常见的使用高性能计算的场景包括基因处理、金融建模与仿真、计算化学、物理建模与仿真、政府及科研项目等。在这些HPC应用中，通常需要使用HPC集群来帮助我们快速完成计算，从而减少研发成本和时间。比如基因公司为了完成遗传病组学研究，通常一次需要研究上万份基因的样本，分析上百T的数据，如果用自己机房的服务器来完成计算分析，需要数年的时间，如果使用HPC集群，提交基因分析任务，我们能使用集群的分布式资源管理器来调度并最大化的利用机器资源，在数天内完成分析任务，大大的节省计算的时间。常见的高性能计算的场景还包括：视频转码与编码、流体力学、天气预测、材料仿真、汽车碰撞仿真、风险建模、分子建模、上下文搜索、物流建模、地震勘探数据处理、基因数据计算、天体物理、深度学习、动画建模、微电子验证、图像处理、地理信息系统等。 2. 什么是高性能计算 通常所说的高性能计算使用的硬件一般分为两种情况： 高性能计算机 高性能计算机通常指使用了很多处理器（作为单个机器一部分）的机器。 比如说国内的高性能计算机“天河”、“曙光”、“神威-太湖之光”等，如“神威-太湖之光”由40个运算机柜和8个网络机柜组成，一台机柜装有1024块处理器，计算速度12亿亿次浮点运算次数。 高性能计算机集群 使用某一集群中的多台计算机（作为单个计算资源操作）的计算系统和环境。 这是通过将多台计算机，通过软件的方式组成集群，由集群的分布式资源管理器来负责集群中服务器资源的监控、调度等，我们可以将集群看做单个计算资源，然后将任务提交到集群，分布式资源管理器负责将任务调度到具体服务器执行。 比如在2013年的超级计算机500强的竞赛中，AWS使用多个C3实例组建了高性能计算机集群，使用了26496个核，计算峰值速度达593.5万亿次浮点运算次数，当年排名世界第64位。 当我们需要高性能计算的时候，通常由于机房的资源比较固定，很难有很多服务器给我们来组建集群，而借用高性能计算机如“曙光“，”神威“的成本非常高，也不太现实。这时在云上搭建高性能计算集群就非常方便，因为云上有无限量的计算及存储的资源，资源更弹性，计算过程中可以根据业务压力，调整集群服务器数量；在完成计算后，我们可以释放所有计算资源，大大降低了计算成本。 3. 如何使用AWS云搭建HPC集群 通过 AWS，您能在数分钟内完成高性能计算集群的创建，并将并行 HPC 任务的数量增加到大多数本地 HPC 环境都无法支持的规模，从而提高研究速度并缩短获得成效的时间。AWS 可按需提供针对特定应用程序进行优化的 CPU、GPU 和 FPGA 服务器，有众多的服务器类型选择，无需巨额资金投入，从而帮助降低成本。您有权限访问面向紧密耦合、IO 密集型和存储密集型工作负载的完全等分的高带宽网络，这使您能够在数千个核心之间横向扩展，从而更快获得成效。 4. 集群管理软件CFNCluster 您的HPC集群可能拥有成百上千台机器，手工搭建HPC集群意味着你需要创建所有服务器，配置所有软件，这个过程太复杂。为了简化这个操作，AWS提供了CFNCluster集群管理软件，它是由AWS开发和维护的高性能计算集群的框架，能帮助你在数分钟内完成集群的创建和生产部署，CFNCluster创建的集群支持SGE,OpenLava，Torque等高性能计算框架。下图是CFNCluster和HPC集群的关系图： 通过上图可知，通常我们需要在一台服务器上安装CFNCluster软件，然后通过CFNCluster创建和管理多个HPC的集群，HPC集群中的服务器安装了SGE, OpenLava等分布式资源管理器，你可以根据需要配置分布式资源管理器的类型 ，你也可以使用Cloudwatch监控服务，根据业务压力动态调整(AutoScaling)HPC集群计算节点的数量。当HPC集群创建完成后，你可以像以往使用HPC集群一样通过Master节点访问你的HPC集群。下面示例详细介绍了安装CFNCluster和创建HPC集群的详细过程： (1) 在AWS云中创建一台EC2服务器（使用Amazon Linux的AMI），并运行sudo pip install cfncluster安装CFNCluster，示例如下： sudo pip install cfncluster You are using pip version 6.1.1, however version 9.0.1 is available. […]

Emily Freebairn，亚马逊AWS软件开发工程师 翻译 Ye Zhou | 原文链接 通常，工程师希望在一组实例中执行操作任务。 但是，这些任务中的许多任务需要以受控的速度进行，并在出现问题时获得反馈。 此外，管理员还通常希望确保工程师只能执行指定的操作。 “运行命令”是Amazon EC2系统管理器（SSM）的一部分，旨在让您远程和安全地管理实例。 “运行命令”提供了一种简单的方法来自动执行常见的管理任务，如运行shell脚本、安装软件或修补程序等等。 “运行命令”允许您在多个实例上执行命令，并提供对结果的可见性。通过与AWS身份和访问管理（IAM）的集成，您可以精确控制用户可以在实例上执行的操作权限。 “运行命令”执行的所有操作均由AWS CloudTrail记录，允许您审核对系统的更改。 在本文中，演示了如何执行命令来收集实例的诊断信息。 由于系统容量是按需添加，系统的容量会随时变化。为了减少实例出现意外的可能性，命令可以以受控的速度运行。 如果出现失败，您将收到通知以进行事后分析。 要确保您不会意外运行其他命令，请使用具有锁定权限的自定义操作来执行指定任务。 演练 在本节中，我将向您展示如何使用Auto Scaling设置实例，创建自定义SSM文档，然后在Auto Scaling组中的所有实例上运行命令。 同时展示了如何设置Amazon CloudWatch事件，以便在遇到问题时收到通知。 步骤1：使用Auto Scaling组启动实例 要使用“运行命令”，实例需要以下内容： 安装并运行Amazon SSM代理 出站互联网连接 附加适当的IAM角色 SSM代理与“运行命令”服务通信以接收命令并发送输出，并使用IAM角色授予调用服务的权限。 对于这篇文章，使用Auto Scaling组来创建一组正确配置的实例。 有关分步说明，请参阅Auto Scaling入门。 这里是一个使用了五个实例的Auto Scaling组的示例。 步骤2：创建自定义文档 “运行命令”使用文档来指定要在实例上执行的操作。文档是由JSON定义的AWS资源，它们包括您指定的步骤和参数。 AWS提供了一组执行常见任务的文档，例如运行shell脚本，配置CloudWatch，安装应用程序等。 此外，您可以为自己的文档编写特定任务。 因为IAM策略允许您控制用户被授权使用哪些文档，因此可以通过将一个指定用户限制到某个文档子集来锁定该用户可以执行的操作。 这里是一个文档的例子，它找出最消耗内存的进程。 { “schemaVersion”: “2.0”, “description”: “Instance Diagnostics”, “parameters”: { }, […]

我们在 re:Invent 2016 发布了 Amazon AppStream 2.0。利用此应用程序流式处理服务可将 Windows 应用程序交付到桌面浏览器。 AppStream 2.0 是完全托管的，并通过运行一般用途的应用程序提供一致的可扩展性能，提供经过优化的计算、内存优化的流式处理实例，并通过 NICE DCV (安全的高保真流式传输协议) 交付。我们的企业和公共部门客户已经开始使用 AppStream 2.0，代替安装在内部的旧应用程序流式处理环境。他们使用 AppStream 2.0 将商业和业务线应用程序交付到桌面浏览器。我们的 ISV 客户使用 AppStream 2.0 将其应用程序原样迁移到云中，不对其代码做任何更改。这些客户专注于演示、研讨会和商业 SaaS 订阅。 我们收到有关 AppStream 2.0 的良好反馈，并且在非常快速地 (即使按照 AWS 标准来看也是很快的) 增加新的功能。到目前为止，今年我们增加了映像生成器、基于 SAML 2.0 的联合访问、CloudWatch 监控、队列 Auto Scaling、简单网络设置、用户文件永久存储 (Amazon S3 提供支持)、VPC 安全组支持以及内置的用户管理，包括用户 Web 门户。 全新 GPU 驱动流式处理实例 很多客户告诉我们，他们需要使用 AppStream 2.0 向其用户交付专业的设计、工程、HPC […]

原文: https://aws.amazon.com/blogs/devops/performing-bluegreen-deployments-with-aws-codedeploy-and-auto-scaling-groups/ 作者：Jeff Levine，Amazon Web Services解决方案架构师 AWS提供的服务能够帮助大家利用云的力量来满足开发和部署的需求。AWS CodeDeploy可自动将代码部署到Amazon EC2或本地实例，并支持蓝绿部署方式。在这篇博文中，将讨论蓝绿部署的好处，并展示如何实现。 蓝绿部署的好处 蓝绿部署涉及两个生产环境： 蓝色环境指代正在使用的生产环境。 绿色环境则将发布一个新版本。 以下是蓝绿部署的一些优点： 可在绿色环境下进行测试，而不会中断蓝色环境。 切换到绿色环境不需要停机，只需要重定向用户流量。 问题发生时，可很方便地从绿色环境回滚到蓝色环境，只要将流量重定向回蓝色环境即可，而无需重新构建。 需要变更时，利用不可变基础设施原则初始化新的实例，避免实例配置产生不一致性。 AWS CodeDeploy提供了两种蓝绿部署的方式： 第一种，AWS CodeDeploy为Auto Scaling组创建了副本，启用新的Amazon EC2实例，将应用程序部署到这些新实例，然后重定向用户流量重定到新部署的代码。 第二种，可使用实例标签或Auto Scaling组来选择用于绿色环境的实例。AWS CodeDeploy会将代码部署到标记的实例上。 那么，如何设置你的第一个蓝色环境？最佳做法，当然是采用AWS CodeDeploy的in-place部署方式。当然也可以从已有的空白Auto Scaling组开始。 蓝绿部署的示例 我们来看一下如何使用Auto Scaling组来实现蓝绿部署。 概述 下图中，示例环境包括一组Amazon EC2实例，可作为AWS CodeDeploy的工作站。服务发布管理员或开发人员可以使用此工作站部署新版本的代码。蓝色环境包含一个Auto Scaling组，其中另有两个实例用作Web服务器。 Web服务器，最初将包含应用程序的第一个版本和AWS CodeDeploy客户端。负载均衡器以轮转的方式，将流量引导到两个Web服务器。 服务发布管理员使用工作站实例，将新版本的应用程序推送到AWS CodeDeploy，并启动蓝绿部署。 AWS CodeDeploy会创建Auto Scaling组的副本，启动两个新的Web服务器实例，并安装新版本的应用程序，然后将负载均衡器重定向到新实例。 原实例仍然是原Auto Scaling组的一部分。 如果需要，均可重新关联到负载均衡器中。 构建该示例的先决条件 以下是需要的准备工作。 具有使用Amazon EC2，Amazon S3，Amazon VPC，AWS CodeDeploy和AWS CloudFormation权限的IAM用户。 选定构建示例环境的AWS区域和可用区域。 Amazon EC2密钥对。 […]

Amazon DynamoDB 拥有十万多的客户，客户身处各种行业，使用案例也各不相同。这些客户依赖于 DynamoDB 在任何规模下都能提供的一致性能和覆盖全球 16 个地理区域的服务网络。最近我们注意到一个趋势，客户正在使用 DynamoDB 来为他们的无服务器应用程序提供支持。这是一个很好的搭配：使用 DynamoDB，您无需考虑配置服务器、执行操作系统和数据库软件修补或跨可用区配置复制以确保高可用性之类的事情 – 您只需创建一些表，然后开始添加数据，其他的交给 DynamoDB 处理。 DynamoDB 提供预置容量模式，可以让您设定您的应用程序所需的读取和写入容量。尽管这让您无需考虑服务器，在 AWS管理控制台中进行简单的 API 调用或按钮单击就可以对表的配置进行更改，但客户已经在询问我们，有没有方法让管理 DynamoDB 容量变得更加轻松。 现在，我们推出了 Auto Scaling for DynamoDB，可帮助您实现表和全局二级索引容量管理的自动化。您只要指定所需的目标使用率，并提供读取和写入容量的上限和下限。之后，DynamoDB 将利用 Amazon Cloudwatch 警报来监控吞吐量占用情况，并根据需要上调或下调预置容量。Auto Scaling 对于所有新表和索引默认启用，您还可以对现有表和索引配置此功能。即使您不在左右，DynamoDB Auto Scaling 也将监控您的表和索引，并根据应用程序流量的变化自动调整吞吐量。这使您可以更加轻松地管理 DynamoDB 数据，帮助您最大程度地提高应用程序的可用性，并帮助您降低 DynamoDB 成本。我们来看看它是如何工作的…… 使用 Auto Scaling 现在当您创建新表时，DynamoDB 控制台会提出一组适宜的默认参数。您可以原样接受它们，也可以取消选中“Use default settings”，然后输入您自己的参数： 以下是您输入自己的参数的方式： 目标使用率以占用容量与预置容量的比值来表示。以上参数将允许提供足够的空间，使占用容量能够在读取或写入请求突增时倍增 (请参阅容量单位计算，了解更多有关 DynamoDB 读取和写入操作与预置容量之间关系的信息)。预置容量的变化是在后台发生的。 Auto Scaling 的实际操作 为了了解这项重要的新功能的实际操作，我按照入门指南中的指示进行了操作。我启动了一个全新的 […]

Kong是一个开源的API GW及微服务管理层，基于Nginx, Cassandra或者PostgreSQL构建，最初由Mashape开发，用于为其API Marketplace管理超过15,000个API和微服务，并于2015年开源。Kong具有如下优点： 可扩展性：通过简单地添加更多的机器，Kong可以轻松地水平缩放，这意味着您的平台可以处理几乎任何负载，同时保持低延迟。 模块化：可以通过添加新的插件来扩展，并通过RESTful Admin API轻松配置所有插件。 平台无关性：Kong可以运行在任何地方，包括本地数据中心及公有云，支持物理机，虚机及容器部署。 目前Kong的最新版本为0.10.2，支持的插件如下： 认证：Basic Authentication, Key Authentication, OAuth2.0 Authentication, OAuth 2.0 Introspection, HMAC Authentication, JWT, LDAP Authentication 安全：ACL, CORS, Dynamic SSL, IP Restriction, Bot Detection 流控：Rate Limiting, Response Rate Limiting, Request Size Limiting 无服务器架构：AWS Lambda, OpenWhisk 分析监控：Galileo, Datadog, Runscope 内容转换：Request Transformer, Response Transformer, Correlation ID 日志：TCP/UDP/HTTP Logging, File […]

去年年底，我宣布推出预览版 Lambda@Edge，并谈论了如何使用它在靠近客户的位置 (低延迟) 智能地处理 HTTP 请求。申请并获得预览版访问权的开发人员一直在很好地使用它，并为我们提供了大量非常有用的反馈意见。在预览期间，我们添加了生成 HTTP 响应和支持 CloudWatch Logs 的功能，并根据反馈意见更新了路线图。 现已正式发布 今天我很高兴地宣布 Lambda@Edge 现已正式发布！您可以使用它来： 检查 Cookie 并重写 URL 以执行 A/B 测试。 根据 User-Agent 标头将特定对象发送给用户。 通过在将请求传递到源之前查找特定标头来实现访问控制。 添加、删除或修改标头以将用户指引到不同的缓存对象。 生成新的 HTTP 响应。 干净利落地支持旧 URL。 修改或缩减标头或 URL 以提高缓存利用率。 向其他 Internet 资源发出 HTTP 请求，并使用结果自定义响应。 Lambda@Edge 允许您创建基于 Web 的丰富且个性化的用户体验。由于它正迅速成为当今世界的常态，因此您不需要配置或管理任何服务器。您可以直接上传代码 (在Node.js 中编写的 Lambda 函数)，并选择您为分发版创建的其中一个 CloudFront 行为以及所需的 CloudFront 事件： 在本例中，我的函数 (假设名为 EdgeFunc1) […]

1. 简介 Amazon EC2 Container Service (ECS)是Amazon提供的一项Docker容器管理服务，可以让您轻松构建、运行、管理您的Docker容器服务。ECS Service是ECS的重要组件，它可以在集群中运行指定数量的任务，当某个任务不可用时，它会重新启动新的任务，维持住任务的指定数量。这个特性从一定程度上保证了服务的可用性，但当面对突发流量，ECS本身并不能动态地进行任务数量的扩展，当流量较少时，ECS也无法动态地进行任务数量的缩减。为解决此问题，可以使用Auto Scaling和Amazon CloudWatch等实现服务的自动伸缩，保证服务高可用。本文将介绍一个运用Auto Scaling在ECS中实现服务高可用的方案，并通过对方案构建过程的剖析，让您对高可用、自动伸缩的服务架构有更进一步的了解。 2. 方案构建 2.1 整体结构图 本方案使用AWS CloudFormation模板声明整个资源堆栈所需资源和相关配置，并实现自动化构建。关于AWS CloudFormation相关知识，请通过以下链接了解：CloudFormation入门。 从上面这个结构图可以看出以下主要组成部分： 初始由两个跨AZ的Container Instance组成的ESC Cluster。 初始ESC Service中有两个task。 Service Auto Scaling与CloudWatch结合，当Service维度的 CPUUtilization与Threshold满足设定的触发条件时，触发CloudWatch Alarm，CloudWatch Alarm根据设定的Scaling Policy进行Task数量伸缩。 Auto Scaling Group与CloudWatch结合，当Cluster维度的CPUReservation与Threshold满足设定的触发条件时，触发CloudWatch Alarm，CloudWatch Alarm根据设定的Scaling Policy进行实例数量的伸缩。 2.2 准备工作 (1)准备好CloudFormation模板脚本 请从这里（点我）下载用于构建整个资源堆栈的模板脚本文件。 或者通过点击下面按钮来运行堆栈： (2)准备好Lambda Function 本方案在Auto Scaling Group中的实例关闭时，会调用一个实现自动切换Draining状态的Lambda Function。那么在构建整个堆栈之前，需要先准备好这个Lambda Function。这里我们使用Python编写了这个脚本auto_drain.py来实现此功能。您可以了载包含了这个脚本的压缩包（点我）。 下载完成后，请将它上传到您账户上同个Region的S3 Bucket中。记住这个S3 Bucket Name，在构建堆栈时，将它传给Lambda Function S3 […]

1. 背景 Docker hub作为docker官方镜像仓库，提供了大量Docker镜像的托管服务。但使用它来托管企业私有Docker镜像存在一些问题，比如： （1）Docker hub托管私有镜像的服务目前只面对收费账户； （2）使用Docker hub托管私有镜像并不适合一些特殊场景，比如工作环境网络是内网，不允许访问外网，那就更不可能到Docker hub去下载镜像。 在这种情况下，如果能构建一个安全可靠的Docker私有库，将会是一个更好的选择。本文将介绍在Amazon EC2 Container Service基础上结合AWS Elastic LoadBalancer、AWS Autoscaling Group、AWS S3及Docker官方提供的registry镜像构建安全、高可用的Docker私有库的方案，帮助您轻构实现这一需求。 2. 方案详解 我们会使用AWS CloudFormation服务，使用自定义的模板脚本声明所需的资源，实现自动化构建。接下来结合我们的模板脚本对本方案进行详细介绍。 注意：以下内容与代码相关部分只贴出主要代码，部分代码用…表示省略；红字部分请替换成您自己账号相关的信息。 完整模板代码地址：https://s3-us-west-2.amazonaws.com/blog.leonli.org/registry.yml          或者点击按钮直接在控制台中运行： 2.1 架构图 根据以上架构图，基本数据传输过程为： （1）Docker客户端向镜像仓库发送的pull/push等命令事实上都是通过docker daemon转换成restful请求的形式再发送给镜像仓库的。在本架构中，我们利用AWS Elastic LoadBalancer(简称ELB)接收客户端发来的请求，作为整个架构的接入层。由于我们要求数据是通过TLS加密传输的，所以我们需要使用AWS IAM中的server certificate（由AWS IAM账户上传的TLS证书）与ELB关联，实现对客户端发来的请求进行加密。 （2）ELB会将请求反向代理给后端分布在不同可用区的两台Container Instance（安装了Docker运行环境的EC2实例），Container Instance中运行了Docker registry服务。当请求到达registry时，我们需要首先使用内置在registry中的用户认证文件（比如本架构中使用apache htpasswd创建的基本用户名密码保护文件），进行用户认证，认证不通过，则驳回请求，认证通过，才可以读写数据。 （3）我们将数据统一存储在一个只供创建者使用的S3 Bucket中。 2.2 基于AWS ECS运行Docker Registry服务 Amazon EC2 Container Service (ECS) 是一项高度可扩展的高性能容器管理服务，它让您能够在托管的 Amazon EC2 […]

最近我介绍过 DynamoDB Auto Scaling，并演示了它如何使用多个 CloudWatch 警报来实现 DynamoDB 表的自动容量管理。此功能在后台使用了一种更为通用的 Application Auto Scaling 模型，我们计划以后逐渐在多项不同 AWS 服务中投入使用该模型。 这一新的 Auto Scaling 模型包括一项重要的新功能，我们称之为目标跟踪。在创建使用目标跟踪的 Auto Scaling 策略时，需要为特定 CloudWatch 指标选择一个目标值。然后，Auto Scaling 旋转相应的旋钮 (打个比方) 推动指标趋向于目标，同时调整相关的 CloudWatch 警报。比起使用初始步进扩展策略类型来手动设置范围和阈值而言，采用对应用程序有意义的任何指标驱动的单元来指定期望的目标，通常来说要更简单，也更为直接。不过，您可以结合使用目标跟踪和步进扩展来实现高级扩展策略。例如，您可以使用目标跟踪实现扩展操作，使用步进扩展实现缩减操作。 现在面向 EC2 现在我们为 EC2 Auto Scaling 增加了目标跟踪支持。您现在可以创建应用程序负载均衡器请求计数、CPU 负载、网络流量或自定义指标 (Request Count per Target 是新指标，也是在今天发布) 驱动的扩展策略： 这些指标都具有同一个重要的特性：添加额外的 EC2 实例会推动指标下降 (但不会改变总体负载)，反之亦然。 要创建使用目标跟踪的 Auto Scaling 组，只需输入策略名称、选择一个指标，然后设置所需的目标值： 您可以选择禁用策略的缩减功能。如果禁用，您可以手动缩减，也可以使用独立的策略。您可以使用 AWS Management Console， […]