云服务器内容精选

  • 前提条件 待切换操作系统的挂载有系统盘。 如果原服务器使用的是密码登录方式,切换操作系统后使用密钥登录方式,请提前创建密钥文件。 如果您使用私有镜像切换操作系统请参考《 镜像服务 用户指南》提前完成私有镜像的制作。 如果需要指定云服务器的镜像,请提前使用指定云服务器创建私有镜像。 如果需要使用本地的镜像文件,请提前将镜像文件导入并注册为云平台的私有镜像。 如果需要使用其他区域的私有镜像,请提前复制镜像。 如果需要使用其他账号的私有镜像,请提前完成镜像共享。
  • 切换须知 切换操作系统后,将不再保留原操作系统,并删除原有系统盘及清除系统盘数据,包括系统盘上的系统分区和所有其它分区,请做好数据备份。详细内容,请参考备份弹性云服务器。 切换操作系统不影响数据盘数据。 切换操作系统后IP地址和MAC地址不发生改变。 切换操作系统成功后会自动开机。 切换操作系统后不支持更换系统盘的云硬盘类型。 切换操作系统后,您的业务运行环境需要在新的系统中重新部署。 切换操作系统后,当前操作系统内的个性化设置(如DNS、主机名等)将被重置,需重新配置。 重新配置云服务器DNS信息请参考:怎样配置弹性云服务器的DNS和NTP信息? 重新配置主机名请参考:怎样使修改的静态主机名永久生效?
  • 后续处理 如果切换操作系统前后都是Linux系统,且数据盘设置了开机自动挂载分区。切换操作系统后,数据盘分区挂载信息会丢失,请更新/etc/fstab配置。 在/etc/fstab写入切换后的分区信息。 建议您先备份/etc/fstab文件。 详细操作请参考初始化Linux数据盘(fdisk),设置开机自动挂载磁盘分区。 挂载分区。挂载分区后即可开始使用数据盘。 mount diskname mountpoint 执行以下命令,查看挂载结果。 df -TH 如果操作系统切换失败,公有云平台支持重试功能,用户可重新执行2-7,切换操作系统。 重试后,如果仍未成功,可联系客服进行人工恢复。
  • 约束限制 XGPU功能仅在Nvidia Tesla T4、V100上支持。 HCE内核版本为5.10及以上版本。 GPU实例已安装535.54.03版本的NVIDIA驱动。 GPU实例已安装18.09.0-300或更高版本的docker。 受GPU虚拟化技术的限制,容器内应用程序初始化时,通过nvidia-smi监测工具监测到的实时算力可能超过容器可用的算力上限。 当CUDA应用程序创建时,会在GPU卡上申请一小部分UVM显存(在Nvidia Tesla T4上大约为3 MiB),这部分显存属于管理开销,不受XGPU服务管控。 暂不支持同时在裸机环境以及该环境直通卡的虚拟机中同时使用。 XGPU服务的隔离功能不支持以UVM的方式申请显存,即调用CUDA API cudaMallocManaged(),更多信息,请参见NVIDIA官方文档。请使用其他方式申请显存,例如调用cudaMalloc()等。 XGPU允许用户动态禁用UVM的方式申请显存,禁用方法参考uvm_disable接口说明。
  • XGPU服务使用示例 影响XGPU服务的环境变量如下表所示,您可以在创建容器时指定环境变量的值。容器引擎可以通过XGPU服务获得算力和显存。 表1 影响XGPU服务的环境变量 环境变量名称 取值类型 说明 示例 GPU_IDX Integer 指定容器可使用的GPU显卡。 为容器分第一张显卡: GPU_IDX=0 GPU_CONTAINER_MEM Integer 设置容器内可使用的显存大小,单位 MiB。 为容器分配的显存大小为5120MiB: GPU_CONTAINER_MEM=5120 GPU_CONTAINER_QUOTA_PERCENT Integer 指定显卡算力分配百分比。 算力支持最小1%粒度的划分,推荐最小算力不低于4%。 为容器分配50%的算力比例: GPU_CONTAINER_QUOTA_PERCEN=50 GPU_POLICY Integer 指定GPU使用的算力隔离的策略。 0:不隔离算力,即原生调度。 1:固定算力调度。 2:平均调度。 3:抢占调度。 4:权重抢占调度。 5:混合调度。 6:权重弱调度。 算力隔离策略示例详见XGPU算力调度示例。 设置算力隔离策略为固定算力调度:GPU_POLICY=1 GPU_CONTAINER_PRIORITY Integer 指定容器的优先级。 0:低优先级 1:高优先级 创建高优先级容器: GPU_CONTAINER_PRIORITY=1 以nvidia的docker创建两个容器为例,介绍XGPU服务的使用方法,数据规划如下。 表2 数据规划 参数 容器1 容器2 说明 GPU_IDX 0 0 指定两个容器使用第一张显卡。 GPU_CONTAINER_QUOTA_PERCENT 50 30 为容器1分配50%算力,为容器2分配30%算力。 GPU_CONTAINER_MEM 5120 1024 为容器1分配5120MiB显存,为容器2分配1024MiB显存。 GPU_POLICY 1 1 设置第一张显卡使用固定算力调度策略。 GPU_CONTAINER_PRIORITY 1 0 指定容器1为高优先级容器,容器2为低优先级容器。 配置示例: docker run --rm -it --runtime=nvidia -e GPU_CONTAINER_QUOTA_PERCENT=50 -e GPU_CONTAINER_MEM=5120 -e GPU_IDX=0 -e GPU_POLICY=1 -e GPU_CONTAINER_PRIORITY=1 --shm-size 16g -v /mnt/:/mnt nvcr.io/nvidia/tensorrt:19.07-py3 bash docker run --rm -it --runtime=nvidia -e GPU_CONTAINER_QUOTA_PERCENT=30 -e GPU_CONTAINER_MEM=1024 -e GPU_IDX=0 -e GPU_POLICY=1 -e GPU_CONTAINER_PRIORITY=0 --shm-size 16g -v /mnt/:/mnt nvcr.io/nvidia/tensorrt:19.07-py3 bash
  • 约束限制 当弹性云服务器实例规格和替换的OS系统均在支持的实例规格和支持迁移的公共镜像列表中时,才支持系统迁移。 操作系统迁移过程中涉及rpm卸载、安装及更新,操作系统存在异常重启的风险。请在迁移前做好操作系统的系统盘备份,可以通过快速创建云服务器备份。 建议操作系统内存剩余大于128MB,系统盘空间剩余大于5GB(指迁移工具运行需要的系统盘空间,不包含数据备份的空间),boot分区可用空间大于200MB。 请避免自定义的RPM包和操作系统组件rpm重名。否则迁移时,自定义的rpm会被迁移工具删除。 迁移操作系统后不支持更换系统盘的云硬盘类型。 系统迁移过程中,待迁移系统中存在部分冲突包。迁移工具会自动删除冲突包以完成系统迁移。冲突包列表详见冲突包列表。 系统迁移过程中会使用dnf组件,如果系统原有的dnf组件版本过低会影响升级过程,可以先卸载原系统的dnf组件。 父主题: 将操作系统迁移至HCE 2.0
  • 使用概述 您可通过下列方法使用Huawei Cloud EulerOS。 首次创建弹性云服务器实例时,推荐使用HCE公共镜像。 将操作系统切换为HCE。 如果现有的弹性 云服务器配置 (网卡、磁盘、VPN等配置的类型和数量)都不需要改变,仅需要修改弹性云服务器的操作系统镜像,并且您的软件和原操作系统耦合度较低,适配到HCE改动较小,建议使用系统切换,可快速切换到HCE。 将操作系统迁移为HCE。 如果现有的弹性云服务器配置(网卡、磁盘、VPN等配置的类型和数量)都不需要改变,操作系统软件的配置参数希望保留,可以通过操作系统迁移的方式迁移到HCE。 仅支持迁移至Huawei Cloud EulerOS 2.0标准版和Huawei Cloud EulerOS 1.1CentOS兼容版,不支持迁移至其他HCE镜像版本。 表1 系统切换和迁移的区别 区别 系统切换 系统迁移 数据备份 切换操作系统会清除系统盘数据,包括系统盘上的系统分区和所有其它分区。 切换操作系统不影响数据盘数据。 迁移操作系统不会清除系统盘数据,为避免系统软件的数据丢失,建议将其备份。 迁移操作系统不影响数据盘数据。 个性化设置 切换操作系统后,当前操作系统内的个性化设置(如DNS、主机名等)将被重置,需重新配置。 迁移操作系统后,当前操作系统内的个性化设置(如DNS、主机名等)不需重新配置。
  • 约束与限制 仅HCE 2.0 x86架构支持使用tbwmcli命令。 仅允许root用户执行tbwmcli命令。 tbwmcli命令同一时间只能在一个网卡使能Qos功能,多个网卡不支持并行使能网络QoS。 网卡被插拔重新恢复后,原来设置的QoS规则会丢失,需要手动重新配置网络QoS功能。 不支持cgroup v2。 升级oncn-tbwm软件包不会影响升级前的使能状态。卸载oncn-tbwm软件包会关闭对所有设备的使能。 仅支持识别数字、英文字母、中划线“-” 和下划线“_”四类字符类型的网卡名,其他字符类型的网卡不被识别。 实际使用过程中,带宽限速有可能造成协议栈内存积压,此时依赖传输层协议自行反压,对于udp等无反压机制的协议场景,可能出现丢包、ENOBUFS、限流不准等问题。 收包方向的网络限速依赖于TCP的反压能力,在非TCP协议的场景中,网络包已经收至目标网卡,不支持对于收包方向的网络限速。 不支持tbwmcli、tc命令和网卡命令混用,只能单独使用tbwmcli工具进行限速。例如,某个网卡上已经设置过tc qdisc规则的情况下,对此网卡使能网络QoS功能可能会失败。
  • hung task 当内核检测到进程处于D状态超过设定的时间时,上报hung task异常。 原理 进程其中一个状态是TASK_UNINTERRUPTIBLE,也叫D状态,处于D状态的进程只能被wake_up唤醒。内核引入D状态时,是为了让进程等待IO完成。正常情况下,IO正常处理,进程不应该长期处于D状态。 hung task检测进程长期处于D状态的原理,内核会创建一个线程khungtaskd,用来定期遍历系统中的所有进程,检查是否存在处于D状态超过设置时长(默认120秒)的进程。如果存在这样的进程,则打印并上报相关警告和进程堆栈。如果配置了hung_task_panic(通过proc或内核启动参数配置),则直接发起panic。 触发方法 创建内核线程,设成D状态,scheduler释放时间片。
  • page allocation failure page allocation failure是申请空闲页失败时,系统上报的错误。当程序申请某个阶数(order)的内存,但系统内存中,没有比申请阶数高的空闲页,即触发内核报错。 原理 Linux使用伙伴系统(buddy system)内存分配算法。将所有的空闲页表(一个页表的大小为4K)分别链接到包含了11个元素的数组中,数组中的每个元素将大小相同的连续页表组成一个链表,页表的数量为1、2、4、8、16、32、64、128、256、512、1024,所以一次性可以分配的最大连续内存为1024个连续的4k页表,即4MB的内存。 假设申请一个包括256个页表的内存,指定阶数order为6,系统会依次查找数组中的第9、10、11个链表,上一个为空,表示没有此阶数的空闲内存,查找下一个,直到最后一个链表。 如果所有链表均为空,申请失败,则内核上报错误page allocation failure。输出报错信息,描述申请阶数为6的内存页失败: page allocation failure:order:6 触发方法 用alloc_pages连续申请高阶数内存页(例如order=10),不释放,直到申请失败。
  • warning Warning是操作系统在运行时,检测到需要立即注意的内核问题(issue),而采取的上报动作,打印发生时的调用栈信息。上报后,系统继续运行。 原理 Warning是通过调用WARN、WARN_ON、WARN_ON_ONCE等宏来触发的。 导致Warning的原因有多种,需要根据调用栈回溯,找到调用Warning宏的具体原因。Warning宏并不会导致系统运行状态发生改变,也不提供处理Warning的指导。 触发方法 根据系统调用构造Warning条件。
  • panic Kernel panic是指操作系统在监测到内部的致命错误,并无法安全处理此错误时采取的动作。内核触发到某种异常情况,运行kernel_panic函数,并尽可能把异常发生时获取的全部信息打印出来。 原理 导致异常的原因多种多样,通过异常打印的调用信息,找到调用kernel_panic的原因。常见的原因包括内核堆栈溢出、内核空间的除0异常、内存访问越界、内核陷入死锁等。 触发方法 内核态读0地址。
  • Bad mm_struct Bad mm_struct错误通常是由于内核中的一个或多个mm_struct数据结构被破坏或损坏所导致。 原理 mm_struct是Linux内核中的一个重要数据结构,用于跟踪进程的虚拟内存区域。如果该数据结构被破坏,可能会导致进程崩溃或系统崩溃。这种错误通常内存异常导致,例如mm_struct区域的内存被踩踏、内存越界等。 触发方法 无人为触发方法,当硬件错误,或者Linux系统内核代码错误时会触发Bad mm_struct。
  • MCE (Machine Check Exception) Machine Check Exception (MCE) 是CPU发现硬件错误时触发的异常(exception),上报中断号是18,异常的类型是abort。 原理 导致MCE的原因主要有:总线故障、内存ECC校验错、cache错误、TLB错误、内部时钟错误等。不仅硬件故障会引起MCE,不恰当的BIOS配置、firmware bug、软件bug也有可能引起MCE。 MCE中断上报,操作系统检查一组寄存器称为Machine-Check MSR,根据寄存器的错误码执行对应的处理函数(函数实现依赖不同的芯片架构实现)。 触发方法 无人为触发方法,当总线故障、内存ECC校验错、cache错误、TLB错误、内部时钟错误等时会触发MCE。
  • global OOM Linux的OOM killer特性是一种内存管理机制,在系统可用内存较少的情况下,内核为保证系统还能够继续运行下去,会选择结束一些进程释放掉一些内存。 原理 通常oom_killer的触发流程是:内核为某个进程分配内存,当发现当前物理内存不够时,触发OOM。OOM killer遍历当前所有进程,根据进程的内存使用情况进行打分,然后从中选择一个分数最高的进程,终止进程释放内存。 OOM killer的处理主要集中在mm/oom_kill.c,核心函数为out_of_memory,函数处理流程为: 通知系统中注册了oom_notify_list的模块释放一些内存,如果从这些模块中释放出了一些内存,直接结束oom killer流程;如果回收失败,进入下一步。 触发oom killer通常是由当前进程进行内存分配所引起。如果当前进程已经挂起了一个SIG_KILL信号或者正在退出,直接选中当前进程,终止进程释放内存;否则进入下一步。 检查panic_on_oom系统管理员的设置,决定OOM时是进行oom killer还是panic。如果选择panic,则系统崩溃并重启;如果选择oom killer,进入下一步。 进入oom killer,检查系统设置,系统管理员可设置终止当前尝试分配内存、引起OOM的进程或其它进程。如果选择终止当前进程,oom killer结束;否则进入下一步。 调用select_bad_process选中合适进程,然后调用oom_kill_process终止选中的进程。如果select_bad_process没有选出任何进程,内核进入panic。 触发方法 执行占用大内存的程序,直到内存不足。