yarn 如何提高资源利用率如何提升资源利用率

转载

mob64ca1414c613 2023-12-18 23:30:15

文章标签 yarn 如何提高资源利用率 java python 大数据人工智能 文章分类 Yarn 大数据

根据Gartner的数据，全球数据中心的平均利用率约为10％到15％，这对于提高资源效率不是一个好方法。资源利用方面的领导者，尤其是Google和Netflix，表现更好，达到50％到70％。

不幸的是，如果我们不做任何事情，资源效率可能会变得更糟。公共云和自动化工具使过度配置变得容易。通常，这是处理复杂性和不可预测需求的唯一方法（毕竟，过度配置总比倒塌更好。）

随着企业迁移到公共云并添加诸如IoT之类的新工作负载，对公共云的需求正在增长。据估计，到2020年，对数据中心容量的需求增长预计将达到50％至300％。

我们如何提高技术资源效率？

2016年3月，《经济学人》估计数据中心占全球能源使用量的2％。相比之下，航空业使用了全球能源的2％至2.5％，并且人们在争夺新跑道。考虑到航空业是一个相当节能的行业，这也许是不公平的。燃油成本占航空业务成本的很大比例，而降低能耗是直接的竞争优势。

同时，在技术领域，我们对节省成本的兴趣较少，而对新功能或产品推出速度的兴趣更多。流行的微服务架构使自治团队可以非常快速地发布功能。但是，与老式的整体设备相比，每个VM部署一个微服务通常会降低服务器利用率。

容器编排

好消息是，编排可以大大提高数据中心的效率。这正是Google和Netflix获得更高分数的方式。

容器可以实时扩展，而花费数分钟即可为虚拟机增加容量。因此，您不必添加新机器，而只需重新利用现有基础架构，以专注于临时的紧急任务即可。我们称其为“微扩展”，以区别于传统的虚拟机自动扩展。 Netflix和Google以这种方式使用微尺度技术，同时减少了能源消耗和托管成本。

微型缩放还可以与VM自动缩放一起使用，以重新分配资源以满足紧急需求，同时花时间让更多的VM容量联机。这有可能使系统更具弹性，而不会过度配置。

微型引擎

Orchestrators使您能够构建有用的工具来管理容器化工作负载。所有协调器（Docker Swarm，Mesos，Kubernetes，Nomad，ECS）都具有干净的RESTful API，可让您查看整个集群中正在运行的内容以及停止和启动任务。

如果您的任务可以停止并快速重新启动（ “牛而不是宠物” ），那么您有可能决定停止一些对于满足特定需求高峰至关重要的任务，并使用释放的资源来扩展或扩展至关重要的服务。这可以实时发生，因为容器和协调器将使您在几秒钟内重新利用现有的基础架构。

某些协调器支持基于CPU和内存的微缩放。这可能很有用，但是也存在问题-例如，由于代码效率低下，容器可能会占用大量CPU。与其使用CPU和内存，不如使用与客户活动相关的指标，而不是使用。

为此，您需要访问实时需求指标。 CloudWatch和类似服务通常落后几分钟，这还不够快。最初，作为需求量度，我们使用的是队列长度，而不是实时系统，例如负载均衡器（NGINX）或SQS或Rabbit。

如果队列长度超出目标，我们将按比例放大容器，然后在处理积压后按比例缩小。任何备用容量均可用于优先级较低的任务。到目前为止，我们将支持Docker远程API和Marathon / Mesos，并将提供更多协调器。

您可以通过运行我们的微扩展引擎来扩展本地NSQ队列，并使用Docker Compose自己尝试一下。您可以在GitHub上的代码microscaling / microscaling上找到。

元数据，容器和业务流程

但是我们很快遇到了微尺度化的问题。我们如何知道某个特定的容器映像是用于重要服务还是用于诸如批处理服务等非关键服务？协调者还需要知道应该应用于容器的CPU和内存限制。容器的开发人员应该对所需的资源有很好的了解。但是如何将这些信息传递给可能由一个单独的团队管理的协调器呢？

我们需要某种方式将元数据添加到容器图像中，以告诉我们类似的信息。幸运的是，Dockerfile具有执行此操作的正式方法。在构建微型缩放引擎时，我们意识到元数据和标签是缩放和有效使用编排器的关键。

在Docker v1.6中，Red Hat贡献了一种将元数据添加到Docker容器映像的机制：标签。这是在图像中添加注释或许可条件的标准方法。实际上，标签的唯一问题是它们的使用率不高（少于20％的时间）。

架构和格式

标签是自由文本键/值对。这很灵活，但可能会造成混乱，不安全和不一致，尤其是因为：

您可以多次标记图像或容器。

容器继承其图像的标签。

新密钥将覆盖具有相同名称的旧密钥。

幸运的是，Docker已经为标签定义了一些格式化建议：

使用您的域的反向DNS表示法来命名您的键名（例如 com.mydomain.mykey ）。
不要使用com.docker.x ， io.docker.x或org.dockerproject.x作为键名中的命名空间。这些是保留的。
使用小写字母数字. 和- （如[a-z0-9-.] ）的键名，并以字母数字开头和结尾。
不要在键名中使用连续的点和破折号。
不要一次使用单个标签命令添加标签。每个标签都会在图像上添加一个新层，因此效率低下。在一个呼叫中添加多个标签，您可以在其中：

LABEL vendor=ACME\ Incorporated \
      com.example.is-beta= \
      com.example.is-production="" \
      com.example.version="0.0.1-beta" \
      com.example.release-date="2015-02-12"

这些准则没有得到强制执行，但是毫无疑问，工具会随之实现（例如， github.com/garethr/docker-label-inspector ）。

使用标签

关于默认标签和业务流程特定标签的争论很多（请参阅本文末尾的“参考”部分）。首先，我们决定为自己的图像添加最少的初始标签集。这些标签对于大多数公共Docker映像应该很有用。它们尚未包括微尺度元数据。

"Labels": {
    "org.label-schema.build-date": "2016-06-22T08:39:00Z",
    "org.label-schema.docker.dockerfile": "/Dockerfile",
    "org.label-schema.license": "Apache-2.0",
    "org.label-schema.url": "https://microscaling.com",
    "org.label-schema.vcs-ref": "995bb0a",
    "org.label-schema.vcs-type": "git",
    "org.label-schema.vcs-url": "https://github.com/microscaling/microscaling.git",
    "org.label-schema.vendor": "Microscaling Systems"
}

Label-Schema.org

我们还帮助建立并加入了label-schema.org社区，以帮助定义标准标签的默认名称空间。我们希望就正确，最有用的标签达成社区共识，以默认情况下将其添加到任何容器中。

不幸的是，您当前无法在Dockerfile中使用动态标签。您可以对标签值进行硬编码，但是它们很容易过时，这有点麻烦。 Docker建议您使用ARG命令将这些动态标签传递到Dockerfile中。

docker build --build-arg BUILD_DATE=`date -u +"%Y-%m-%dT%H:%M:%SZ"` \
             --build-arg VCS_REF=`git rev-parse --short HEAD` .

在我们的案例中，我们构建了一个makefile来自动将动态标签传递到我们的Dockerfile中，该文件也在我们的GitHub repo中。随意看看。

MicroBadger

为了鼓励使用标准标签，我们还创建了一个网站（ microbadger.com ）在DockerHub上显示公共图像的元数据。如果您是公共图像的维护者，则该网站可以让您向DockerHub页面和GitHub自述文件添加徽章。在DockerHub上，您可以向您的用户显示用于构建映像的确切git commit。这可以通过添加到图像的标签来实现。