本文为您介绍在公共资源组进行服务部署的相关说明。

背景信息

公共资源组中用户无须关注底层资源池,可以直接部署服务,以按量付费的方式来使用底层资源。目前支持两种服务部署的方式,一种是为实例指定CPU核数,该方式与普通服务的部署方式相同;另外一种方式是使用ECS机型来指定实例的资源规格。本文为您介绍在公共资源组进行服务部署的以下说明。
  • 支持部署ECS机型以及服务配置,详情请参见机型部署
  • 需要用户开通EAS服务到用户客户端网络的场景以及字段配置,详情请参见网络开通
  • 部署在公共资源组中的服务日志可以投递到用户的SLS日志仓库中,如何在SLS中进行日志采集,详情请参见日志投递
  • 自定义服务在线上运行时因为用户代码问题会发生crash,如何设置Core文件以便进行排查,详情请参见Core文件设置

机型部署

目前支持部署的机型如下所示。
实例规格 实例名称
ecs.c5.6xlarge c5(24vcpu+48GB)
ecs.c6.2xlarge c6(8vcpu+16GB)
ecs.c6.4xlarge c6(16vcpu+32GB)
ecs.c6.6xlarge c6(24vcpu+48GB)
ecs.c6.8xlarge c6(32vcpu+64GB)
ecs.g5.6xlarge g5(24vcpu+96GB)
ecs.g6.2xlarge g6(8vcpu+32GB)
ecs.g6.4xlarge g6(16vcpu+64GB)
ecs.g6.6xlarge g6(24vcpu+96GB)
ecs.g6.8xlarge g6(32vcpu+128GB)
ecs.gn5-c28g1.7xlarge 28vcpu+112GB+1*P100
ecs.gn5-c4g1.xlarge 4vcpu+30GB+1*P100
ecs.gn5-c8g1.2xlarge 8vcpu+60GB+1*P100
ecs.gn5-c8g1.4xlarge 16vcpu+120GB+2*P100
ecs.gn5i-c4g1.xlarge 4vcpu+16GB+1*P4
ecs.gn5i-c8g1.2xlarge 8vcpu+32GB+1*P4
ecs.gn6i-c16g1.4xlarge 16vcpu+62GB+1*T4
ecs.gn6i-c24g1.12xlarge 48vcpu+186GB+2*T4
ecs.gn6i-c24g1.6xlarge 48vcpu+186GB+2*T4
ecs.gn6i-c4g1.xlarge 4vcpu+15GB+1*T4
ecs.gn6i-c8g1.2xlarge 8vcpu+31GB+1*T4
ecs.gn6v-c8g1.2xlarge 8vcpu+32GB+1*V100
ecs.r6.2xlarge r6(8vcpu+64GB)
ecs.r6.4xlarge r6(16vcpu+128GB)
ecs.r6.6xlarge r6(24vcpu+192GB)
ecs.r6.8xlarge r6(32vcpu+256GB)
ecs.g7.2xlarge g7(8vcpu+32GB)
ecs.g7.4xlarge g7(16vcpu+64GB)
ecs.g7.6xlarge g7(24vcpu+96GB)
ecs.g7.8xlarge g7(32vcpu+128GB)
ecs.c7.2xlarge c7(8vcpu+16GB)
ecs.c7.4xlarge c7(16vcpu+32GB)
ecs.c7.6xlarge c7(24vcpu+48GB)
ecs.c7.8xlarge c7(32vcpu+64GB)
ecs.r7.2xlarge r7(8vcpu+64GB)
ecs.r7.4xlarge r7(16vcpu+128GB)
ecs.r7.6xlarge r7(24vcpu+192GB)
ecs.r7.8xlarge r7(32vcpu+256GB)
ecs.g7.16xlarge g7(64vcpu+256GB)
ecs.c7.16xlarge c7(64vcpu+128GB)
ecs.r7.16xlarge r7(64vcpu+512GB)
ecs.gn7i-c8g1.2xlarge 8vcpu+30GB+1*A10
ecs.gn7i-c16g1.4xlarge 16vcpu+60GB+1*A10
ecs.gn7i-c32g1.8xlarge 32vcpu+188GB+1*A10
ecs.gn6e-c12g1.3xlarge 12vcpu+92GB+1*V100
ecs.g6.xlarge g6(4vcpu+16GB)
ecs.c6.xlarge c6(4vcpu+8GB)
ecs.r6.xlarge r6(4vcpu+32GB)
ecs.g6.large g6(2vcpu+8GB)
ecs.c6.large c6(2vcpu+4GB)
ecs.r6.large r6(2vcpu+16GB)
ecs.c7a.large AMD(2vcpu+4GB)
ecs.c7a.xlarge AMD(4vcpu+8GB)
ecs.c7a.2xlarge AMD(8vcpu+16GB)
ecs.c7a.4xlarge AMD(16vcpu+32GB)
ecs.c7a.8xlarge AMD(32vcpu+64GB)
ecs.c7a.16xlarge AMD(64vcpu+128GB)
ecs.g7a.large AMD(2vcpu+8GB)
ecs.g7a.xlarge AMD(4vcpu+16GB)
ecs.g7a.2xlarge AMD(8vcpu+32GB)
ecs.g7a.4xlarge AMD(16vcpu+64GB)
ecs.g7a.8xlarge AMD(32vcpu+128GB)
ecs.g7a.16xlarge AMD(64vcpu+256GB)
使用机型来部署服务的配置方式如下,需在服务配置文件中增加cloud.computing.instance_type字段,用以指定实例的机型。
{
  "name": "tf_serving_test",
  "model_path": "http://eas-data.oss-cn-shanghai.aliyuncs.com/models/model.tar.gz",
  "processor": "tensorflow_gpu_1.12",
  "cloud":{
      "computing":{
          "instance_type":"ecs.gn6i-c24g1.6xlarge"
      }
  },
  "metadata": {
    "instance": 1,
    "cuda": "9.0",
    "memory": 7000,
    "gpu": 1,
    "cpu": 4
  }
}
说明 通过eascmd create service.json命令也可以完成服务的部署。eascmd的使用,请参见eascmd命令使用说明

网络开通

以下两种场景需要用户开通EAS服务到用户客户端的网络。
  • 正向访问

    用户在用户侧VPC中以直连的方式请求EAS服务。

  • 反向访问

    用户在EAS服务中反向访问用户VPC中的服务,如Redis等。

网络打通依赖云网络提供的弹性网卡(ENI)机制,用户需要提供一个客户端的vSwitch ID及Security Group ID,实例启动时会自动在用户提供的vSwitch中创建ENI绑定到EAS的服务实例上,通过该ENI实现EAS服务实例与用户侧网络的双向互通。
说明 当指定vSwitch ID时,默认会打通到该vSwitch所在的整个VPC的网络,若用户所在的VPC为10.0.0.0/8网段,则会与EAS网段产生冲突,导致服务不可用,此时需要使用显式指定客户端需要打通的子网段,以避免大网段的网段冲突问题。
您可以通过cloud.networking相关字段,指定网络打通的相关参数。
  • cloud.networking相关字段如下所示。
    字段 说明
    cloud.networking.security_group_id 客户端ECS节点所归属的安全组ID。
    cloud.networking.vswitch_id 客户端vSwitch ID,会在该vSwitch中创建ENI,需保证该vSwitch中空闲IP充足,否则会导致EAS实例无法创建。
    说明 默认会打通该vSwitch所属VPC的整个网段,如果选中的vSwitch所属交换机网段为10.0.0.0/8,则会与服务端网段产生冲突导致实例网络中断,该性能下除设置该字段外,同时需要设置destination_cidrs字段来显式指定需要打通的客户端VPC中的网段地址,如只需要打通该vSwitch一个网段,则可在destination_cidrs字段中填入该vSwitch所对应的网段信息,例如10.1.1.0/24。
    cloud.networking.destination_cidrs 显式指定要打通的客户端网段,该网段均需归属于上述vSwitch所属的同一VPC中。
    cloud.networking.default_route 指定默认的网络出口。可选eth0/eth1,默认为eth0,在打通用户VPC网络后,实例中会有两张网卡,eth0为EAS VPC中的主网卡,eth1为用户VPC中的辅助网卡,默认出口流量会从eth0流出,而EAS VPC是不开放公网的,典型场景当用户需要在容器中访问公网时,则可以在用户VPC中通过开通公网NAT网关打开公网访问,然后将EAS的实例default_route设置为eth1,则访问公网的流量可经由eth1到达用户VPC再经由用户VPC中的NAT网关到达公网。
  • 使用方式如下。
    {
      "model_path": "http://eas-data.oss-cn-shanghai.aliyuncs.com/models/lr_xingke4.pmml",
      "name": "test_pmml",
      "processor": "pmml",
      "metadata": {
        "instance": 1,
        "cpu": 3,
        "memory": 2000
      },
      "cloud": {
        "networking.security_group_id": "sg-2vce4xxvy5hn1hmjx7yh",
        "networking.vswitch_id": "vsw-2vcbbihcy3cg8fjdpdvdl",
        "networking.destination_cidrs": "10.2.0.0/8"
      }
    }

日志投递

部署在公共资源组中的服务日志可以投递到用户的SLS日志仓库中,用户需通过如下步骤来完成SLS的日志采集。

  1. 创建日志仓库。
    您需要在SLS中创建project和logstore,名称可自行选取,也可选择使用现存的日志仓库。详情请参见日志服务
  2. 创建机器组。
    1. 在SLS的机器组管理页面,通过自定义标识来创建资源组。
      创建机器组
      说明 EAS服务中专用的自定义标识为eas-log-group-{region_id},例如张家口的自定义标识为eas-log-group-cn-zhangjiakou
    2. 当服务部署完成后,打开机器组的配置页面,在机器组状态列表中可以看到实例心跳状态,OK表示机器组运行正常。
      机器组状态
  3. 配置logtail。
    机器组创建完成后,可以新建logtail对容器中的日志进行采集。若用户在服务中向本地文件中写入日志,则可以通过SLS的Docker文件-容器类型的logtail配置采集容器中的日志文件。快速数据接入

Core文件设置

自定义服务在线上运行时因为用户代码问题可能会发生crash。为了便于排查,需要将crash时产生的core文件导出进行分析,而公共资源组中服务以Serverless的方式运行,要获取到core文件需要用户自行挂载外部存储,如NAS等,并将设置core_pattern来指定core文件存储的路径为NAS挂载的目录。设置core_pattern的方法如下,需在服务部署时,增加runtime.core_pattern字段。
{
  "model_path": "http://eas-data.oss-cn-shanghai.aliyuncs.com/models/lr_xingke4.pmml",
  "name": "test_pmml",
  "processor": "pmml",
  "runtime": {
    "core_pattern": "/corefiles/%h-%t-%e-%p.core"
  },
  "metadata": {
    "instance": 1,
    "cpu": 3
  }
}