校内党政部门、直属单位、院系的所建设及管理的信息系统，如运行需要可申请虚拟机。
但此申请不适用于信息系统的开发或测试环境。
租赁的虚拟机如应用迁移、下线或系统替换等原因不再使用的，用户须提交申请注销虚拟机。
注销时，用户单位的注销申请并加盖单位公章，将申请表提交至大学服务中心申请处理。
注销申请内容应包含：
- 注销理由
- 虚拟机名称
- IP地址
- 约定可关机注销日期
- 注销申请人姓名、工号、联系方式
在约定关机注销日期前，应确保虚拟机上数据已无用可销毁，或已完成备份归档。
数据中心提供以下两种虚拟化平台服务：
- X86-64 架构：采用 VMware ESXi 7.0.3 虚拟化平台，支持 Windows Server 、Linux、FreeBSD、Solaris 等 X86 版操作系统。
- AArch64 架构：采用 Huawei FusionCube 8.2.0 虚拟化平台，仅支持 Aarch64 (ARM 架构) 版的 Linux，不兼容 X86 代码的应用。
虚拟机租赁业务可提供预安装的虚拟机（服务器）操作系统包括以下这些：
VMware ESXi 7.0.3 提供的虚拟机操作系统：
- openEuler 24.03 LTS X86-64，内核Linux 6.X，生命周期（扩展支持）至2028年3月
- openEuler 22.03 LTS X86-64，内核Linux 5.10，生命周期（社区联合维护）至2028年3月
- OpenCloudOS V9.2 (LTS) X86-64，内核Linux 6.X，生命周期（维护支持）至2033年4月30日
- Windows Server 2019 Standard，64位，生命周期（扩展终结日）至2029年1月9日
- Windows Server 2022 Standard，64位，生命周期（扩展终结日）至2031年10月14日
Huawei FusionCube 8.2.0 提供的虚拟机操作系统：
- openEuler 24.03 LTS AArch64，内核Linux 6.X，生命周期（扩展支持）至2028年3月
- openEuler 22.03 LTS AArch64，内核Linux 5.10，生命周期（社区联合维护）至2028年3月
- Rocky Linux 9.X AArch64，内核Linux 5.14，生命周期至2032年5月31日
- OpenCloudOS V9.2 (LTS) AArch64，内核Linux 6.X，生命周期（维护支持）至2033年4月30日
国内开源社区发行的 Linux 操作系统为：
- openEuler，为 openEuler 是由开放原子开源基金会（OpenAtom Foundation）孵化及运营的开源项目，战略捐赠人是华为公司。
- OpenCloudOS，是由腾讯与合作伙伴共同倡议发起，是中立、开放的操作系统及生态。
至本 FAQ 条目编订日，OpenAnolis 或 Anolis OS 因其生命周期页面都处于断链状态，导致我们无法核定其生命周期，所以无法向用户提供此操作系统。
如有列表以外的特殊操作系统需求，请先联系服务支持确认。
操作系统的生命周期主要包括以下几个阶段：
- 开发与测试：设计、开发及测试操作系统。
- 发布：操作系统正式推向时长
- 支持阶段：
主支持：提供功能更新和安全补丁。
扩展支持：主要提供安全更新。 - 停止支持：厂商停止所有更新和服务。
使用过期的 EOL（End of Life），即超出生命周期的操作系统，其有以下危害：
- 安全风险增加：不再接收安全更新，易受攻击和恶意软件影响。
- 技术支持缺失：无法获得官方的技术支持和帮助。
- 兼容性问题：新软件和硬件可能无法兼容，导致无法正常使用。
- 性能问题：系统可能无法充分利用新硬件，导致性能下降。
- 合规性风险：可能不满足数据保护法规要求，带来法律风险。
- 业务连续性风险：系统更容易遭受攻击或故障，导致业务中断。
简而言之，就是操作系统从开发至最终停止支持的整个时间段。在这个过程中，用户可获得不同的支持和服务，直至停止支持后，需升级或更换系统以确保安全性。操作系统是信息系统的一个根基，使用过期的操作系统与食品、药物安全上使用过期原材料生产无本质上的区别。
虚拟机不可用于以下用途：
- 安装数据库，数据中心提供独立的高可用集群数据库（租户）服务，数据库有远程灾备、离线数据保护功能。如有需要，可另行申请数据库（租户）服务。
- 备份，数据中心所有的虚拟机、存储，均有数据保护策略，如：定时快照、远程灾备、离线备份策略，租户无需再自行建立备份系统。
- 存储用途，数据中心提供独立的应用系统数据存储服务，所使用的存储为企业级大型存储，有定时快照、远程灾备数据保护策略，且有安全访问策略、性能优异。因此，严禁使用虚拟机自行提供效率低下的存储服务。
虚拟机如使用容器部署应用，无论在 Docker 还是 Kubernetes（K8s）网络模式使用 Bridge 模式，会为容器分配私有地址，地址段通常是根据 Docker 和 Kubernetes 的默认配置来决定的。请先确定其使用的 IPv4 地址段，仅可使用 192.168.0.0/16（192.168.0.0-192.168.255.255），不可使用：172.16.0.0/12（172.16.0.0-172.31.255.255）及10.0.0.0/8（10.0.0.0-10.255.255.255）地址段，以此避免数据通讯上的混乱，所造成的部分用户无法使用该应用。容器如使用自定义、overlay等模式手动设置私有地址时，也要遵循上述 IPv4 私有地址段使用原则。
Docker 默认桥接网络地址段
在 Docker 中，默认情况下，当你启动一个容器并且没有显式指定网络时，Docker 会自动将容器连接到默认的桥接网络 docker0。这个网络通常使用以下私有地址段：IPv4 地址段：172.17.0.0/16
这意味着默认情况下，Docker 容器将被分配在这个子网内的一个 IP 地址。例如，172.17.0.2、172.17.0.3 等。这个地址段属于 RFC1918 定义的私有地址空间，但已被校园网所使用。
Kubernetes 默认桥接网络地址段
在 Kubernetes 中，默认情况下，Pods 的网络配置可以由多种不同的 CNI（Container Network Interface）插件来处理。常见的 CNI 插件包括 Flannel、Calico、Cilium 等，它们各自可能会有不同的默认地址段。
例如，Flannel 是一个常用的 CNI 插件，它默认使用以下私有地址段：IPv4 地址段：10.244.0.0/16，此地址段虽然也属于 RFC1918 定义的私有地址空间，但已被校园网所使用。
而 Calico 另外一个常用的 CNI 插件，它的默认地址段可以是：IPv4 地址段：192.168.0.0/16，这段的地址可以使用。
Kubernetes 的网络配置通常是通过集群级别的配置来确定的，可以通过修改集群的网络配置来更改默认的地址段。
虚拟机部署了容器 Docker 和 Kubernetes (K8S) 后，应正确设置域名转发，否则无法正确使用数据中心提供的存储（NAS）、数据库租户等服务。
数据中心提供的存储（NAS）、数据库租户服务，均使用域名方式访问，严禁使用固定IP地址访问这些服务。
域名转发是指将特定域名的 DNS 查询请求发送到指定的 DNS 服务器的过程。这对于确保容器中应用能够正确解析外部服务的地址至关重要。
数据中心接受容器域名解析转发的 DNS 服务器为：202.116.64.1 和 202.116.64.2
当然，下面是一个关于如何在使用 Docker 和 Kubernetes 部署应用时正确设置域名转发的技术支持 FAQ。这份 FAQ 包含了基本的概念解释、配置步骤以及常见问题解答。
以下设置方法仅供参考，容器管理员应根据自己的情况做出判断，及选用恰当的 DNS 转发设置。配置案例中，除 202.116.64.1 和 202.116.64.2 外，所有域名均为假设。
在 Docker 中如何设置域名转发
1. 使用 Docker 守护进程配置
编辑 Docker 守护进程配置文件（通常位于 /etc/docker/daemon.json）。
添加或修改 dns 属性，指定您希望使用的 DNS 服务器。
{
"dns": ["202.116.64.1", "202.116.64.2"]
}
重启 Docker 服务以应用更改。
sudo systemctl restart docker
2. 在 Docker Compose 文件中设置
在 docker-compose.yml 文件中，为每个服务定义 dns 属性。
version: '3'
services:
web:
image: nginx
dns:
- 202.116.64.1
- 202.116.64.2
在 Kubernetes 中如何设置域名转发
1. 修改 CoreDNS 配置
访问 Kubernetes 集群的 CoreDNS 配置文件（通常是 `Corefile`），通常位于 `kube-system` 命名空间下的 ConfigMap `coredns` 中。
添加或修改转发规则，以便将特定域名的查询请求转发到外部 DNS 服务器。
nas.storage.local:53 {
forward . 202.116.64.1 202.116.64.2
}
应用更改并重启 CoreDNS Pods。
kubectl -n kube-system edit configmap coredns
2. 使用 Pod 的 DNSPolicy
在 Pod 定义中设置 dnsPolicy 和 dnsConfig 字段，直接为特定的 Pod 指定 DNS 服务器。
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
dnsPolicy: "None"
dnsConfig:
nameservers:
- 202.116.64.1
- 202.116.64.2
searches:
- ns1.svc.cluster-domain.example
- my.domain.com
options:
- name: ndots
value: "2"
如修改了 CoreDNS 配置，不需要重启整个集群。只需更新 CoreDNS 的 ConfigMap 并重启 CoreDNS Pods 即可。CoreDNS 会自动检测配置变化并重新加载。
可使用 nslookup 或 dig 工具从 Pod 内部执行 DNS 查询，以验证配置是否按预期工作。
kubectl run -i --tty --image busybox:test --restart=Never dns-test --rm /bin/sh
在 Pod 内部执行
nslookup nas.storage.local
如应用需要访问多个外部服务，每个服务都有不同的 DNS 服务器，可为每个需要特殊 DNS 配置的服务单独设置 Pod 的 dnsConfig。这样，每个服务都可以指向正确的 DNS 服务器。
修改 DNS 配置对集群中的 Pod 影响问题，如果修改的是 CoreDNS 的全局配置，那么这些更改将影响所有使用集群内 DNS 服务的 Pod。如果只修改特定 Pod 的dnsConfig，则仅影响该 Pod。
在 Docker 环境下，磁盘空间可能会因为镜像、容器、卷和网络等资源的积累而逐渐增大。清理这些不再使用的资源可以帮助释放磁盘空间。以下是一些常用的清理方法：
1. 清理未使用的镜像 (Images)
Docker 镜像占用的磁盘空间通常比较大。您可以清理那些不再使用的镜像。
查看所有镜像
docker images
删除未使用的镜像
-
删除单个镜像：
docker rmi <image_id> -
清理所有未使用的镜像：
docker image prune该命令会删除所有悬空的镜像（即没有任何容器使用的镜像）。
-
如果要强制删除所有未使用的镜像和悬空镜像，可以使用：
docker image prune -a注意：
-a参数会删除所有没有容器依赖的镜像，包括没有标签的镜像。
2. 清理未使用的容器 (Containers)
容器虽然停止运行，但仍然占用磁盘空间。可以删除那些不再使用的容器。
查看所有容器（包括已停止的）
docker ps -a
删除单个容器
docker rm <container_id>
删除所有停止的容器
docker container prune
该命令会删除所有已经停止的容器。
3. 清理未使用的卷 (Volumes)
Docker 卷用于持久化数据，可能在删除容器后仍然存在，并占用磁盘空间。可以清理未使用的卷。
查看所有卷
docker volume ls
删除单个卷
docker volume rm <volume_name>
删除所有未使用的卷
docker volume prune
该命令会删除所有未挂载到容器上的卷。
4. 清理未使用的网络 (Networks)
Docker 创建的网络也可能占用磁盘空间，特别是在您创建了多个自定义网络之后。
查看所有网络
docker network ls
删除单个网络
docker network rm <network_name>
删除所有未使用的网络
docker network prune
该命令会删除所有未使用的网络。
5. 全面清理
如果您希望一次性清理 Docker 中所有未使用的资源，可以使用 docker system prune 命令：
删除所有未使用的容器、网络、镜像和卷
docker system prune
该命令会删除：
- 所有停止的容器。
- 所有未使用的网络。
- 所有悬空的镜像。
- 所有未挂载的卷。
删除所有未使用的资源（包括未使用的卷）
docker system prune -a --volumes
-a：删除所有未使用的镜像（包括当前未使用的镜像）。--volumes：同时删除未使用的卷。
6. 清理构建缓存 (Build Cache)
Docker 在构建镜像时会使用缓存以加速构建过程。长时间使用后，这些构建缓存会占用相当大的磁盘空间。
清理构建缓存
docker builder prune
该命令会清理所有未使用的构建缓存。
7. 查看 Docker 使用的磁盘空间
如果您想查看 Docker 使用了多少磁盘空间，可以使用以下命令：
docker system df
该命令会显示 Docker 当前使用的空间，包括镜像、容器、卷和缓存的磁盘占用情况。
8. 定期清理脚本
为了避免 Docker 磁盘空间的过度占用，您可以定期执行清理操作。可以创建一个脚本，并定期通过 cron 或 systemd 来执行清理操作。
例如，可以创建一个清理脚本 docker_cleanup.sh：
#!/bin/bash
# 清理未使用的镜像
docker image prune -af
# 清理停止的容器
docker container prune -f
# 清理未使用的卷
docker volume prune -f
# 清理未使用的网络
docker network prune -f
# 清理构建缓存
docker builder prune -f
# 打印清理结果 docker system df
然后，您可以使用 cron 定期执行该脚本，自动清理不再使用的 Docker 资源。
总结
- 删除未使用的镜像：
docker image prune -a - 删除未使用的容器：
docker container prune - 删除未使用的卷：
docker volume prune - 删除未使用的网络：
docker network prune - 全面清理：
docker system prune -a --volumes - 清理构建缓存：
docker builder prune
以上方法可帮助有效地释放 Docker 环境中的磁盘空间。
用户如因机器资源不足或其他特殊要求需申请超过标准型虚拟机分配的资源（CPU、内存、本地磁盘），须收集相应的信息提供我中心审核以确认是否满足虚拟机使用要求或扩容要求的，提供的信息如下：
1.虚拟机交付后额外增加安装的软件包信息列表以便判断机器所需的资源要求；
2.虚拟机资源不足的须通过以下相应命令或截图采集信息：
（1）linux虚拟机主要使用top、free、ps等命令收集信息，可使用或参考以下命令得到三个输出结果作为申请参考附件内容
运行top -b -n 1 >resource.txt：列出当前虚拟机资源利用情况将结果输出到resource.txt
运行ps aux --sort -rss | head -n 11 > processtop10.txt ：列出当前虚拟机占用资源最大的十个进程将结果输出至processtop10.txt
运行 ss -tulnp >serviceport.txt：列出当前虚拟机已监听的UDP 和TCP端口的对应进程名称以及进程ID将结果输出至serviceport.txt
提供用户关于申请相关的CPU、内存不足的材料或文档
（2）Windows Server虚拟机通过打开任务管理器获取主要应用程序的相应运行状况以及系统CPU、内存使用情况进行截图输出结果至文档作为申请参考附件内容
（3）如应用输出报错中有明显的提示资源不足的信息，如out of memory等字样的，请打包相应日志文档作为申请参考附件内容
（4）提供系统的帐号信息供我中心在必要时登录系统进一步排查
3.按照我们资源使用要求，建议以较少化的节约资源使用型为主，一般系统不建议仅凭主观性感受进行扩容申请，没有材料支撑的申请不支持在我中心的标准型产品上进行扩容。如遇资源不足如CPU，内存（有资料支撑、日常运维数据或具体的运行架构需求）向中心提交工单申请，由后台审核评估后再定，一般情况下CPU不提供扩容，内存也以后台监测确认后逐级增加为主，限值一般不超过16GB。
4.关键性系统如需在特殊保障时期内扩容须提前申请，一般保障结束后需联系回收资源。
5.本地磁盘一般不扩容，如有大容量存储使用需求，可联系服务中心申请专用存储（NFS、CIFS、S3）解决。
6.另外，虚拟机运行架构较为特殊的，如使用docker容器或ES等具有明确的系统运行环境资源要求的应用需单独讨论其使用必要性。
