亚马逊AWS官方博客

AWS Team

Author: AWS Team

Amazon Aurora 数据库快速克隆

作者:Jeff Barr | 原文链接 今天,我想快速展示一下 Amazon Aurora 中我认为非常有用的一项功能:数据库快速克隆。利用 Aurora 的底层分布式存储引擎,您可以快速、经济地创建数据库的写入时复制克隆。 在我的职业生涯中,我经常需要花时间等待一些有代表性的数据样本,以便用于开发、试验或分析。如果我有一个 2TB 的数据库,则在执行任务之前,等待数据副本准备就绪的时间可能长达几个小时。即使在 RDS MySQL 内,我也仍需花几个小时等待快照副本完成,然后才能测试架构迁移或执行某些分析任务。Aurora 以一种非常有趣的方式解决了这个问题。 借助 Aurora 的分布式存储引擎,我们可以完成一些使用传统数据库引擎通常不可行或成本高昂的操作。通过创建指向各个数据页面的指针,存储引擎可实现数据库快速克隆。然后,当您更改源或克隆中的数据时,写入时复制协议会为该页面创建一个新副本并相应地更新指针。这意味着,以前花 1 小时才能完成的 2TB 快照恢复任务现在只需大约 5 分钟即可完成 – 其中大部分时间用于预配置新 RDS 实例。 创建克隆所花的时间与数据库大小无关,因为我们指向同一存储。这样还可让克隆操作变得非常经济实惠,因为我只需为更改的页面 (而非整个副本) 支付存储费用。数据库克隆仍是一个常规的 Aurora 数据库集群,具有所有相同的持久性保证。 接下来,我们克隆一个数据库。首先,选择一个 Aurora (MySQL) 实例,并从“Instance Actions”中选择“create-clone”。 接下来,将克隆命名为 dolly-the-sheep 并对其进行预配置。 大约 5 分 30 秒后,我的克隆已变为可用状态,然后,我开始进行一些大型架构更改,但发现性能未受到任何影响。由于 Aurora 团队做出了一些改进以支持更快的 DDL 操作,因此,与传统 MySQL 相比,架构更改本身的完成速度更快。如果我想让其他团队成员对架构更改执行一些测试,则随后可以创建克隆的克隆,甚至是三次克隆,依次类推,同时我还能继续更改自己的克隆。这里需要注意的是,从 RDS […]

Read More

新增 – 通过 IP 地址在 AWS 和本地资源间实现应用程序负载均衡

作者:Jeff Barr / 原文链接 去年,我介绍了有关新型 AWS 应用程序负载均衡器的信息,并展示了如何针对 EC2 实例以及在容器中运行的微服务,用它进行第 7 层 (应用程序) 路由。 在向 AWS 迁移的这个漫长过程中,有些客户会构建混合应用程序。这些客户告诉我们,他们希望使用单个应用程序负载均衡器,在现有本地资源以及 AWS 云中运行的新资源组合中分配流量。其他客户则希望将流量分配到分散在两个或多个 Virtual Private Cloud (VPC) 中的 Web 或数据库服务器中,在同一实例上托管 IP 地址不同但端口号相同的多项服务,并为不支持服务器名称指示 (SNI) 的客户端提供基于 IP 的虚拟托管支持。还有一些客户则希望在同一实例上 (或许是在容器内) 托管某项服务的多个实例,同时使用多个界面和安全组来实施精细访问控制。 这些情况会出现在各种混合、迁移、灾难恢复和本地使用情形及场景中。 路由到 IP 地址 应用程序负载均衡器现在可以将流量直接路由到 IP 地址,以满足这些使用情形。这些地址可以与 ALB 位于同一 VPC 中、位于同一区域中的对等 VPC 中、位于与 VPC 连接的 EC2 实例上 (通过 ClassicLink),或者位于 VPN 连接或 AWS […]

Read More

使用云伙伴系统,让您的迁移之旅不再孤单

Edmunds.com 全面迁移到 AWS 的相关经验 伙伴系统这个概念已经使用了数十年,应用范围涵盖生活的许多方面,包括学习、工作和探险。无论涉及哪一方面 (比如大学新生与其学长配对、空军飞行员与其僚机驾驶员或者您的周末潜水伙伴),大多数伙伴系统不外乎两个目的。一个是安全性,通常出现在需要双方相互照顾的体育或危险活动中。另一个是新入学的学生或新来的员工与经验更丰富的伙伴配对以便获得培训和指导,以免出现常见的新手错误,从而自信满满地快速进步。 就我个人来讲,如果 2012 年在我开始全面向云迁移时拥有云伙伴,一定能帮我解决不少难题并省去实验的麻烦。当时,我是北美地区最大的汽车购物网站之一 Edmunds.com 的首席信息官。 但与现在不同的是,当时很难从正在成功迁移的其他公司找到大量伙伴系统资源。如果具备大规模全面的参考案例 (除 Netflix 之外)、托管迁移计划或成熟的咨询合作伙伴生态系统,则迁移工作会容易得多。幸运的是,现在有大量专注于云迁移的人员、流程和技术,这意味着,组织再也不用像我们当时迁移 Edmunds.com 那样孤军奋战了;而且,加快云使用率和更大限度节省成本的相关专业技术水准也在不断提升,这使全面迁移战略变得比以往更加可行。 作为一名终身冲浪爱好者,我可以告诉您,如果有伙伴系统的帮助,即使在危险条件下,冲浪也不是什么了不起的事情。单打独斗被认为是终极精神追求。而如今,如果我要去世界上的陌生地方冲浪,则更愿意采用更加实用的方法。在登上冲浪板之前,我会试着找一位曾经去过那里的“伙伴”,从他那里了解所需的所有海浪相关信息。例如,珊瑚礁有多浅?有鲨鱼出没吗?哪种潮汐状况最适合冲浪?听取了这些方面的建议并学习了别人的经验后,我心中的疑虑通常会打消不少,而且冲浪体验也会得到提升。 最近,我加入了一个前任首席信息官 (他们构成 AWS 企业战略团队) 团体。我们的目标是帮助技术高管思考和拟定其云优先策略,为此我们所采取的一种方法是:制定和简化新型迁移加速计划,以利用我们所积累的知识 (经验是没有压缩算法的)。作为前任首席信息官和 AWS 客户,我们曾经负责过自己的云迁移工作,并在此过程中帮助过各种类型和规模的企业完成了转型,我们的经历就像我到一个新地方冲浪时从伙伴那里获得提示和建议一样。 回想一下,我从 Edmunds.com 迁移经历中得到了三点重要启示;正如您将看到的,即使我们在 2016 年初关闭了最后一个 Edmunds.com 数据中心,我们经历的过程也仍然与大部分企业迁移当前所经历的云采用阶段非常接近 — 我们将完全停止运营这个高性能数据中心 实际上,这不是当时的确切想法。作为当时的首席信息官,我的主要目标是交付技术能力,以超前满足业务需求。在进行云迁移前的 7 年里,我们不知疲倦地工作,开发出了一种被认为极其高效的基础设施运营和 DevOps 实践。但是,这种效率需要企业付出代价,尽管它提供了每日自动发布能力和前所未有的可靠性。这种代价就是,公司需要将越来越多的有限资源分配给支持代码 (私有云和 DevOps 工具集),从而导致没有足够的资源用于面向客户的应用程序代码 (新的客户功能和服务)。我们需要一种新的模式来控制支持代码与客户代码的比率,而不用牺牲任何功能。 2011/2012 年出现的新兴云趋势为企业提供了一种备选方案,它强调与单个公司孤军奋战相比,公有云 (尤其是 AWS 的规模) 能提供更好的基础设施和更优质的服务,而且价格更具竞争力。然而事实却不容乐观,围绕它的新闻层出不穷,报道内容无外乎:与成熟的本地安装相比,云更加昂贵且不太稳定。Netflix 早期曾采用 AWS,当时的情况有力地证明了这一论点:较成熟的大型企业可以在云中运行关键操作;但当时,我们无法为 Edmunds.com 业务找出更类似的参考实施。 同行参考在当时对我们来说极其重要,因为没有任何值得称道的伙伴系统迁移资源可以帮助我们利用成熟的云采用模式。 […]

Read More

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

作者:Iris Fu 和 Cambron Carter 这是一篇由工程总监 Cambron Carter 和 GumGum 的计算机视觉科学家 Iris Fu 联合发布的访客文章。用他们自己的话说,“GumGum 是一家在计算机视觉领域具有深厚专业知识的人工智能公司,能帮助客户充分发挥网络、社交媒体及广播电视每天生产的图像和视频的价值。” 目标物检测的最新技术  检测是许多经典计算机视觉问题之一,已随着卷积神经网络 (CNN) 的采用而得到显著改善。随着 CNN 越来越多地用于图像分类,许多人都依靠粗糙和昂贵的预处理程序来生成候选区域 (region proposal)。通过诸如“选择性搜索”之类的算法根据区域的“客体性”(它们包含目标物的可能性) 生成候选区域,这些区域随后被馈送到训练用于分类的 CNN。虽然这种方法能得到准确结果,但需要很高的运行成本。Faster R-CNN,You Only Look Once (YOLO) 和 Single Shot MultiBox Detector (SSD) 等 CNN 架构通过将定位任务嵌入到网络中来折中解决该问题。 除了预测等级和置信度,这些 CNN 还尝试预测包含某些目标物的区域极值。在本文中,这些极值只是矩形的四个角点,通常称为边界框。先前提到的检测架构需要已经用边界框注释的训练数据,即,该图像包含一个人,而且此人在该矩形区域内。以下是分类训练数据和检测训练数据: 超级帅气又非常能干的工程师 我们开始对使用 Apache MXNet 和 Caffe 来训练 SSD 的体验进行比较。明显动机是以分布式方式训练这些新架构,而不降低准确性。有关架构的更多信息,请参阅“SSD: Single Shot MultiBox Detector”。 训练工具  对于这组实验,我们尝试了几款 […]

Read More

Amazon EC2 Systems Manager让你轻松管理AWS混合云

作者:王宇 摘要: Amazon EC2 Systems Manager(SSM)是一套资源管理、配置的工具集,它不仅能够帮助客户完成AWS云中资源的管理,还能够将客户私有云中的资源统一纳入管理范围,是混合云架构中的管理利器。 IT资源在混合场景下应该如何管理? 对于要不要使用公有云资源的问题对于今天的企业来说已经不再是一个问题了,问题变成了要怎么用,怎么管,以及怎么和现有的企业IT环境进行整合。当前,大量企业客户都存在着部分应用或资源已经上云,而企业自己的数据中心中仍然保留着一部分的应用或资源,如何将这两部分的资源统一管理起来,做到有效的协同,是一个关键问题。而传统的网管或资源管理系统往往还无法支撑这个混合场景下的管理需求。 AWS在云资源管理问题上有着完整的解决方案 AWS从云资源的准备、配置、监控、合规、优化这五个方面提供了完整的云资源管理闭环工具集,今天我们介绍的Amazon EC2 Systems Manager(SSM)是在配置管理环节中的一个最常用的管理工具集。 Amazon EC2 Systems Manager(SSM)工具集 Run Command –远程执行常规管理任务 State Manager –定义和维护操作系统和应用程序的一致配置 Parameter Store – 运维参数的集中管理,如密码和连接字符串 Maintenance Window -在明确定义的时间窗口中安排运维任务,以尽量减少停机时间 Inventory –收集,查询和审计详细的软件清单信息 Patch Management –使用自定义的规则和预先安排的维护窗口维护操作系统补丁程序 Automation –使用简化的工作流自动执行日常运维任务 Run Command Run Command能够通过远程发送命令的方式来管理AWS云以及客户自己数据中心中的IT资源。与以往的Run Command相比,现在还可以控制命令执行的并发数量。 这在远程执行命令时可以有效避免在同一时间使用太多共享资源的问题,例如内部更新或统一执行软件补丁程序。 State Manager State Manager通过“Document”的定义,能够定义和维护操作系统和应用程序的一致配置。 创建一个“Document”,将它与一组目标实例关联,然后创建一个关联策略来指定什么时间和什么频率来应用这个“Document”。 使用标签指定目标可使这个关联应用到未来创建的实例中,并允许它在动态的,自动缩放的环境中按预定义的方式工作。还可以通过选择它并点击Apply Association Now来立即运行这个关联: Parameter Store Parameter Store是一个数字词典,它简化了要分发到实例的许可证密钥,密码和其他数据的存储和管理。 […]

Read More

EKK—基于AWS托管服务的日志收集分析系统

译者:刘磊 应用系统日志的收集分析对于运维来说是至关重要的。一个可靠、安全、可扩展的日志收集分析解决方案在分析应用系统异常终止原因时能够让一切都变得轻松起来。 在这篇博文里,我们会探讨除了流行的ELK(Elasticsearch, Logstash, and Kibana)解决方案之外的另一种选择,EKK解决方案(Amazon Elasticsearch Service, Amazon Kinesis, and Kibana)。EKK架构最大的好处是使得你不再需要自己亲自安装、部署、管理以及扩展日志收集分析系统,而将精力集中在分析日志,排除应用系统异常上面。 下面我们会介绍如何使用EKK架构来收集和分析Apache web服务器的日志,先来看看EKK架构的组成部分。 Amazon Elasticsearch Service是一个流行的搜索和分析引擎,主要用来提供实时的应用系统日志和点击类流量的分析服务。本文中我们会利用Amazon ES将Apache的日志存储并索引起来,作为一项托管服务,Amazon ES可以很轻松地在AWS云上进行部署、操作和扩展。此外使用托管服务,还能大大减轻管理上的工作,例如打补丁、异常监测、节点恢复、备份、监控等等。因为Amazon ES自身内部已经和Kibana进行了集成,所以省去了安装和配置等工作。获取Amazon ES的更多信息,请参考Amazon Elasticsearch Service。 Amazon Kinesis Agent 是一个易于安装的单机版Java应用程序,它负责收集和发送日志数据。它会持续监控Apache web服务器的日志文件,并且将新的数据不断地发送到传输数据流中。同时它还负责文件回滚、生成检查点、异常发生后的重试,以及以时间序列为准可靠地发送日志文件。获取更多利用Amazon Kinesis Agent的信息,请参考Amazon Kinesis Agent和 GitHub 相关项目。 Amazon Kinesis Firehose提供了往AWS中加载流式数据的捷径。本文中,Firehouse会获取并自动加载日志的流式数据到Amazon ES里,随后在S3中还会再进行一次备份。获取Amazon Kinesis Firehose的更多信息,请参考Amazon Kinesis Firehose。 有了AWS CloudFormation的帮助,你只需要使用一个模板就能快速实现EKK架构。模板里准备了Apache web服务器,并使用Amazon Kinesis Agent和Firehose将它的访问日志发送给Amazon ES集群,同时在S3中备份日志数据,最后使用Amazon ES Kibana endpoint来对你的日志进行可视化分析。 AWS CloudFormation template帮你快速完成如下工作: 准备Amazon […]

Read More

利用AWS混合云容灾架构实现企业级IT的云转型(一)

作者:王宇 摘要:AWS混合云容灾架构不但能够实现企业级的应用云容灾,还能够帮助企业级客户平滑实现企业IT的云转型。 在我们谈论容灾时,我们在谈些什么? 容灾是一个非常传统的话题,是在产生IT系统的第一天开始就必须要考虑的问题。总的来说它主要是指“数据中心灾难、区域性灾难和人为误操作”三个方面造成对IT系统的灾难时的恢复工作。 在中国,“两地三中心”的容灾架构已经广泛的被企业级用户认可,成为企业级容灾架构的标准,但由于建设成本高,周期长等原因,实际按照此标准建设的企业少之又少。而AWS的混合云容灾架构,就是在AWS的云环境中实现“两地三中心”,同时利用AWS云中资源的弹性大幅度降低资源成本和建设以及运维的复杂性。 软件定义一切,AWS云容灾解放企业IT生产力 如果企业客户已经在自己的数据中心中完成了容灾环境的搭建,势必消耗了大量了资源,包括机架空间、电力、IT资源、人力资源等等,而容灾环境本身是一个并不产生经济效应的保障性系统,对企业资源的占用巨大。AWS云资源池通过软件定义的方式,能够打造与企业内部完全相同的复杂IT环境,实现企业级应用的完整镜像,随着应用容灾系统迁移至AWS云中,可以将企业现有的容灾中心转变成生产中心,从而扩大客户自建数据中心的承载能力,或大幅降低IT资源的运营成本。 随时容灾演练,确保备用环境可用性 在传统的容灾环境中,容灾演练是一个令人头疼的大问题,因为容灾环境的建设不是“一锤子买卖”,随着生产环境和数据的不断变化,容灾环境必须跟随生产环境改变,否则在发生灾难时就无法实现业务的快速切换和启动,因此,定期的容灾演练是必须的。而传统环境中的容灾演练要配合硬件和软件厂商,耗时耗力,效果还往往不尽如人意。在AWS云环境中,能够轻松实现容灾环境的复制,从而与生产环境并行的实现容灾环境的测试演练,通过实际的演练来验证容灾环境的可用性以及数据的完整性,在演练结束后可以随时将演练环境删除或关停,演练成本和复杂程度都大幅降低。 AWS云容灾实现秒级回滚,解决人为错误 在生产环境中,由于人为的误操作、系统升级、补丁等操作造成的对IT系统以及数据的破坏很难防范,尤其是有一些操作和BUG导致系统在运行一段时间后才能发现故障,而此时容灾环境的数据有可能已经被覆盖,难以恢复。在AWS云中实现的容灾环境能够借助数据快照、数据日志等功能,除了能够保存最新的业务数据意外,还能够实现数据的秒级回滚。在发现系统出现故障后,不但能够切换到容灾环境中的最新数据,还能够选择过去24小时中的任意时间点进行恢复,从而解决了容灾系统中的脏数据问题。 利用AWS容灾环境切换,实现生产系统的平滑上云 现有的IT生产系统环境往往错综复杂且数据量大,让这样的系统上云往往需要冗长的数据搬迁和环境搭建时间,生产系统面临长时间的停机,无法接受。AWS容灾解决方案能够与生产系统并行地传输生产数据,并在云中搭建与企业内部结构相同的生产系统镜像环境,待云中数据与生产中心数据同步一致后,以容灾切换的方式使生产业务切换至AWS云上,最大限度地降低了生产环境的停机时间,实现了平滑上云。 AWS云中容灾,只为实际使用量买单 从容灾系统的TCO上看,AWS容灾解决方案更是具备明显优势。无需前期对硬件、软件的采购和安装,省去了大量前提投入成本。更重要的是,容灾方案中AWS云中资源可以选择不开机或只开启少量小机型资源,对于不开机的资源将完全不收取EC2虚拟机资源的费用,又能保持EC2虚拟机的状态和后台数据的增量更新。经过我们的测算,一个典型的容灾系统项目,以5年为周期进行计算,TCO只需花费原有私有云容灾环境的1/3,而第一年的投入资金更是传统项目的1/10. 总结 容灾虽然是一个非常古老和传统的IT业务,但随着云计算技术的不断成熟和普及,它恰恰成为了一个非常适合率先在公有云中实现的业务。首先它的建设风险低,与生产系统完全并行,前期投入小,无需提前采购,而且它还能够成为企业上云过程中建设自身团队云能力的一个绝好机会,经过云容灾项目之后,企业对AWS云资源、云技术都会有一个全面的了解,且能够利用这个机会验证AWS云环境承载企业生产系统的能力到底如何,再逐步实现企业级IT环境的云转型。 (未完待续) 本次分享的内容先到这里,今后我们会继续针对AWS混合云容灾架构中的诸多关键技术要点进行细致的分享,敬请期待! 如对AWS混合云容灾架构解决方案感兴趣,请联系我们: yuwangcn@amazon.com   作者介绍: 王宇,AWS企业容灾解决方案业务拓展经理,目前负责AWS中国区的混合云、容灾和DevOps产品和解决方案。曾服务于VMware等传统私有云厂商,熟悉传统IT架构和私有云、混合云、公有云的解决方案融合。  

Read More

搭建基于S3的HBase读备份集群

作者:刘磊 当前aws的很多客户已经从将s3作为HBase的存储中获益,这当中包括更低的存储花费、更好的数据可靠性、更容易的扩展操作等待。比如FINRA就通过将HBase迁移到s3上将在存储上的花费降低了60%,此外还带来了运维上的便利,以及架构上的重大优化:将s3作为统一的存储层,实现了更彻底的存储和计算分离。在s3上部署HBase集群,可以让你在集群启动后立即进行数据查询操作,而不用等待漫长的快照恢复过程。 随着Amazon EMR 5.7.0的发布,现在你可以在集群层面进一步提升数据的高可用性和高可靠性,方法是基于同一个s3存储桶建立多个HBase的读备份集群。这会让你的数据通过读备份集群及时地被用户访问,即使在主集群遇到问题关闭的时候,当然你还可以通过在多个可用区中部署读备份集群来进一步增加数据访问服务的可靠性。 接下来的文章将告诉你如何在s3上建立HBase的读备份集群。 HBase 简介 Apache HBase是Apache Hadoop生态体系中的大规模、可扩展、分布式的数据存储服务。同时它还是开源的,非关系型的版本数据库,默认情况下运行在HDFS之上。它的设计初衷是为包含了数百万个列的数十亿行记录提供随机的、强一致性的、实时访问。同时它还和Apache Hadoop、Apache Hive和Apache Pig等大数据服务紧密结合,所以你可以轻易地为并行数据处理提供快速的数据访问。HBase数据模型、吞吐量、和容错机制能很好地为广告、web分析、金融服务和基于时间序列数据的应用等工作负载提供支持。 和其他很多Nosql数据库类似,HBase中的表设计直接影响着数据的查询和访问模式,根据这些模式的不同,查询的性能表现也会有非常大的差异。 HBase on S3 在建立基于S3的HBase读备份集群之前,你必须先学会HBase on S3的部署方法,本段为那些不熟悉HBase on S3架构的人提供了一些基本信息。 你可以通过将S3作为HBase的存储层,来分离集群的存储和计算节点。这使得你可以根据计算需求来规划集群,从而削减开支,毕竟你不再需要为HDFS上存储的3备份数据支付费用了。 HBase on S3架构中的默认EMR配置使用内存和本地磁盘来缓存数据,以此来提升基于S3的读性能。你可以在不影响底层存储的情况下任意地对计算节点进行伸缩,或者你还可以关闭集群来节省开支,然后快速地在另一个AZ中重新进行部署。 HBase on S3读备份集群应用案例 使用HBase on S3架构使得你的数据被安全、可靠地存储起来。它将数据和集群隔离进行存储,消除了因为集群异常终止带来数据丢失的可能性。尽管如此,在一些特殊情况下,你还是会希望数据能获得更高的可用性,比如集群异常终止或者整个AZ失效。另外一个情况是,通过多个集群访问一个S3上的根目录,你可以隔离HBase集群的读写操作,从而来降低集群的压力,提供更高SLA的查询服务。尤其是在主集群因为bulk load、heavy write、compaction等操作变得异常繁忙的时候。 下图展示了没有读备份的HBase on S3架构,在这个场景下,诸如集群终止和AZ失效等异常情况会使得用户无法访问数据。 S3上的HBase根目录,包含了HFile和表的原数据信息。 EMR 5.7.0之前的版本,无法将多个HBase集群指向同一个S3上的根目录,为了获得更高的可用性,你需要在S3上创建多个数据副本,并管理它们之间的一致性。 随着EMR 5.7.0的发布,现在你可以启动多个读备份集群并指向S3桶上同一个根目录,保证了你的数据通过读备份集群它们总是可达的。 下面是一些使用HBase读备份集群的例子,展示了启用前后的一些对比情况。 处于同一个AZ的HBase读备份集群: 处于不同AZ的HBase读备份集群: 基于S3的HBase读备份集群的另一个好处是可以更加灵活地根据具体的工作负载来规划你的集群。比如,虽然你的读负载很低,但还是想要获得更高的可用性,那么就可以启动一个由较小实例组成的规模较小的集群。另一个例子是当你遭遇bulk load时,在高峰期集群需要扩张到很大以满足计算需求,在bulk load结束后,集群可以立即缩减以节省开支。在主集群伸缩的时候,读备份集群可以维持一个固定的规模以对外提供稳定的查询服务。 步骤 使用下列的步骤来启动基于S3 的HBase读备份集群,这项功能只针对EMR 5.7.0之后的版本。 创建使用HBase on […]

Read More

通过机器学习自动优化 DBMS

本客座文章由卡内基梅隆大学的 Dana Van Aken、Geoff Gordon 和 Andy Pavlo 发布。本项目演示学术研究人员如何利用我们的 AWS Cloud Credits for Research Program 实现科学突破。点击:原文链接 数据库管理系统 (DBMS) 是所有数据密集型应用程序最重要的组成部分。它们可以处理大量数据和复杂工作负载。但它们拥有成百上千的配置“开关”,控制了诸如用于缓存的内存量以及将数据写入存储的频率等诸多因素,因此管理起来很困难。组织通常会聘请专家来帮助完成优化活动,但对许多组织来说专家的费用过于高昂。 卡内基梅隆大学数据库研究组的学生和研究人员开发了一款新工具 OtterTune,它可以针对 DBMS 配置开关自动查找较佳的设置。其目标是让每个人都可以轻松部署 DBMS,即使是毫无数据库管理专业知识的人。 与其他 DBMS 配置工具不同,OtterTune 利用在优化之前的 DBMS 部署期间获得的知识来优化新的部署。这可以显著缩短优化新 DBMS 部署所需的时间以及减少所需的资源。为此,OtterTune 维护了一个存储库,用于存储在之前的优化会话中收集的优化数据。它利用此类数据来构建机器学习 (ML) 模型,以捕获 DBMS 对不同配置的响应方式。OtterTune 使用这些模型来指导新应用程序的试验,进而推荐可改善最终目标 (例如,减少延迟或提高吞吐量) 的设置。 在本文中,我们将讨论 OtterTune ML 管道中的每一个组件,并演示这些组件如何彼此交互以优化 DBMS 配置。然后,我们将通过比较 OtterTune 推荐的最佳配置与数据库管理员 (DBA) 及其他自动优化工具选择的配置的性能,评估 OtterTune 对 MySQL 和 Postgres […]

Read More

VMware Cloud on AWS 现已推出

去年我曾向您介绍过我们正在和 VMware 的朋友一道所做的工作,那就是构建 VMware Cloud on AWS。正如我当时所分享的,这是一种原生的完全托管服务,直接在裸机 AWS 基础设施上运行 VMware SDDC 堆栈,以维持客户预期的弹性和安全性。这使得您能够从 AWS 的可扩展性和抗风险能力,以及作为我们的安全优先架构的基本组成部分的网络和系统级硬件功能中获益。 VMware Cloud on AWS 允许您利用您已经了解和拥有的东西。在迁移到公有云后,您现有的技能、在培训方面的投资、操作实践以及对软件许可证的投资仍然有价值且适用。作为这一举措的一部分,您可以将构建和运行数据中心、对硬件进行现代化改造以及进行扩展以满足瞬时或短期需求抛诸脑后。您还可以利用长长的 AWS 计算、数据库、分析、物联网、AI、安全、移动、部署和应用程序服务清单。 初期可用性 在融入了我们通过 Early Access Beta 计划从许多客户和合作伙伴那里收集到的反馈后,今天,在 VMworld 大会上,VMware 与 Amazon 共同宣布推出 VMware Cloud on AWS 的初始版本。该服务初期只在美国西部 (俄勒冈州) 区域推出,可通过 VMware 及 VMware Partner Network 成员获得。该服务旨在支持常见的使用情形,如数据中心扩展、应用程序开发和测试以及应用程序迁移。 该服务由 VMware 销售、交付、支持和计费。它支持自定义大小的虚拟机,运行 VMware 支持的任何操作系统,并使用单租户裸机 AWS 基础设施,以便您可以将 Windows Server 许可证带到云中。每个 […]

Read More