顺德乐从有做阿里巴巴的网站吗,吉林省建设部网站,查网站流量查询工具,wordpress上传功能火山引擎边缘云是以云计算基础技术和边缘异构算力结合网络为基础#xff0c;构建在边缘大规模基础设施之上的云计算服务#xff0c;形成以边缘位置的计算、网络、存储、安全、智能为核心能力的新一代分布式云计算解决方案。边缘存储主要面向适配边缘计算的典型业务场景#…火山引擎边缘云是以云计算基础技术和边缘异构算力结合网络为基础构建在边缘大规模基础设施之上的云计算服务形成以边缘位置的计算、网络、存储、安全、智能为核心能力的新一代分布式云计算解决方案。边缘存储主要面向适配边缘计算的典型业务场景如边缘渲染。火山引擎边缘渲染依托底层海量算力资源可助力用户实现百万渲染帧队列轻松编排、渲染任务就近调度、多任务多节点并行渲染极大提升渲染效率。边缘场景存储挑战这里简单介绍一下在边缘渲染中遇到的存储问题需要对象存储与文件系统的元数据统一实现数据通过对象存储接口上传以后可以通过 POSIX 接口直接进行操作满足高吞吐量的场景需求尤其是在读的时候完全实现 S3 接口和 POSIX 接口。为了解决在边缘渲染中遇到的存储问题团队花了将近半年的时间开展了存储选型测试。最初团队选择了公司内部的存储组件从可持续性和性能上来说都能比较好的满足我们的需求。但是落地到边缘场景有两个具体的问题首先公司内部组件是为了中心机房设计的对于物理机资源和数量是有要求的边缘某些机房很难满足其次整个公司的存储组件都打包在一起包括对象存储、块存储、分布式存储、文件存储等而边缘侧主要需要文件存储和对象存储需要进行裁剪和改造上线稳定也需要一个过程。团队讨论后形成了一个可行的方案CephFS MinIO 网关。MinIO 提供对象存储服务最终的结果写入 CephFS渲染引擎挂载 CephFS进行渲染操作。测试验证过程中文件到千万级时CephFS 的性能开始下降偶尔会卡顿业务方反馈不符合需求。同样的基于 Ceph 还有一个方案就是使用 Ceph RGW S3FS。这个方案基本能满足要求但是写入和修改文件的性能不符合场景要求。经过三个多月的测试之后我们明确了边缘渲染中对于存储的几个核心诉求:运维不能太复杂存储的研发人员能够通过运维文档上手操作后期扩容以及处理线上故障的运维工作需要足够简单。数据可靠性因为是直接给用户提供存储服务因此对于写入成功的数据不允许丢失或者出现跟写入的数据不一致的情况。使用一套元数据同时支持对象存储和文件存储这样业务方在使用的时候不需要多次上传和下载文件降低业务方的使用复杂度。针对读有比较好的性能团队需要解决的是读多写少的场景因此希望有比较好的读性能。社区活跃度在解决现有问题以及积极推进新功能的迭代时一个活跃的社区能有更快的响应。明确核心诉求之后我们发现前期的三个方案都不太满足需求。初识 JuiceFS火山引擎边缘存储团队在 2021 年 9 月了解到了 JuiceFS并跟 Juicedata 团队进行了一些交流。经过交流我们决定在边缘云场景尝试一下。JuiceFS 的官方文档非常丰富可读性很高通过看文档就可以了解比较多的细节。于是我们就开始在测试环境做 PoC 测试主要关注的点是可行性验证运维和部署的复杂度以及跟上游业务的适配是否符合上游业务的需求。我们部署了 2 套环境一个环境是基于单节点的 Redis Ceph 搭建另一个环境是基于单实例的 MySQL Ceph 搭建。在整个环境搭建方面因为 Redis、MySQL 和 Ceph通过 Rook 部署都比较成熟部署运维方案可以参考的资料也比较全面同时 JuiceFS 客户端也能够简单和方便地对接这些数据库和 Ceph因此整体的部署流程非常流畅。业务适配方面边缘云是基于云原生开发和部署的JuiceFS 支持 S3 API同时完全兼容 POSIX 协议还支持 CSI 的方式挂载完全满足我们的业务需求。综合测试后我们发现 JuiceFS 完全契合业务方的需求可以在生产上进行部署运行满足业务方的线上需求。使用 JuiceFS 的收益业务流程优化在使用 JuiceFS 之前边缘渲染主要利用字节跳动内部的对象存储服务TOS用户上传数据到 TOS 中渲染引擎再从 TOS 上将用户上传的文件下载到本地渲染引擎读取本地的文件生成渲染结果再将渲染结果上传回 TOS最后用户从 TOS 中下载渲染结果。整体的交互流程有好几个环节而且中间涉及到比较多的网络以及数据拷贝所以在这个过程中会存在网络抖动或者时延偏高的情况影响用户体验。使用 JuiceFS 后的简化流程使用 JuiceFS 之后流程变成了用户通过 JuiceFS S3 网关进行上传由于 JuiceFS 实现了对象存储和文件系统的元数据的统一可以直接将 JuiceFS 挂载到渲染引擎中渲染引擎以 POSIX 接口对文件进行读写最终用户直接从 JuiceFS S3 网关中下载渲染结果整体的流程更加简洁和高效同时也更稳定。读文件加速大文件顺序写加速得益于 JuiceFS 的客户端缓存机制我们可以将频繁读取的文件缓存到渲染引擎本地极大加速了文件的读取速度。我们针对是否打开缓存做了对比测试发现使用缓存后可以提升大约 3-5 倍的吞吐量。同样因为 JuiceFS 的写模型是先写内存当一个 chunk默认 64M被写满或者应用调用强制写入接口close 和 fsync 接口时才会将数据上传到对象存储数据上传成功后再更新元数据引擎。所以在写入大文件时都是先写内存再落盘可以大大提升大文件的写入速度。目前边缘的使用场景主要以渲染类为主文件系统读多写少文件写入也是以大文件为主。这些业务场景的需求和 JuiceFS 的适用场景非常吻合业务方在存储替换为 JuiceFS 后整体评价也很高。在边缘存储中如何使用 JuiceFSJuiceFS 主要是在 Kubernetes 上部署每个节点都有一个 DaemonSet 容器负责挂载 JuiceFS 文件系统然后以 HostPath 的方式挂载到渲染引擎的 pod 中。如果挂载点出现故障DaemonSet 会负责自动恢复挂载点。在权限控制上边缘存储是通过 LDAP 服务来认证 JuiceFS 集群节点的身份JuiceFS 集群的每个节点都通过 LDAP 的客户端与 LDAP 服务进行验证。我们目前应用的场景主要还是以渲染为主后期会扩展到更多业务场景。在数据访问上边缘存储目前主要通过 HostPath 的方式进行访问后期如果涉及到弹性扩容的需求会考虑使用 JuiceFS CSI Driver 来部署。JuiceFS 存储生产环境实践经验元数据引擎JuiceFS 支持了非常多的元数据引擎如 MySQL、Redis火山引擎边缘存储生产环境采用的是 MySQL。我们在评估了数据量与文件数的规模文件数在千万级大概几千万读多写少场景以及写入与读取性能以后发现 MySQL 在运维、数据可靠性以及事务方面都做得比较好。MySQL 目前采用的是单实例和多实例一主二从两种部署方案针对边缘不同的场景灵活选择。在资源偏少的环境可以采用单实例的方式来进行部署MySQL 的吞吐在给定的范围之内还是比较稳定的。这两种部署方案都使用高性能云盘由 Ceph 集群提供作为 MySQL 的数据盘即使是单实例部署也能保证 MySQL 的数据不会丢失。在资源比较丰富的场景可以采用多实例的方式来进行部署。多实例的主从同步通过 MySQL Operator 提供的 orchestrator 组件实现两个从实例全部同步成功才认为是 OK 的但是也设置了超时时间如果超时时间到了还没有同步完成则会返回成功并打出报警。待后期的容灾方案健全后可能会采用本地盘作为 MySQL 的数据盘进一步提升读写性能降低时延以及提升吞吐。MySQL 单实例配置容器资源CPU8C内存24G磁盘100G基于 Ceph RBD在存储千万级文件的场景下元数据大约占用 30G 磁盘空间容器镜像mysql:5.7MySQL 的 my.cnf 配置ignore-db-dirlostfound # 如果使用 MySQL 8.0 及以上版本需要删除这个配置
max-connections4000
innodb-buffer-pool-size12884901888 # 12G对象存储对象存储采用自建的 Ceph 集群Ceph 集群通过 Rook 部署目前生产环境用的是 Octopus 版本。借助 Rook可以以云原生的方式运维 Ceph 集群通过 Kubernetes 管控 Ceph 组件极大降低了 Ceph 集群的部署和管理复杂度。Ceph 服务器硬件配置128 核 CPU512GB 内存系统盘2T * 1 NVMe SSD数据盘8T * 8 NVMe SSDCeph 服务器软件配置操作系统Debian 9内核修改 /proc/sys/kernel/pid_maxCeph 版本OctopusCeph 存储后端BlueStoreCeph 副本数3关闭 Placement Group 的自动调整功能边缘渲染主打的就是低时延高性能所以在服务器的硬件选择方面我们给集群配的都是 NVMe 的 SSD 盘。其它配置主要是基于火山引擎维护的版本操作系统我们选择的是 Debian 9。数据冗余上为 Ceph 配置了三副本在边缘计算的环境中可能因为资源的原因用 EC 反而会不稳定。JuiceFS 客户端JuiceFS 客户端支持直接对接 Ceph RADOS性能比对接 Ceph RGW 更好但这个功能在官方提供的二进制中默认没有开启因此需要重新编译 JuiceFS 客户端。编译之前需要先安装 librados建议 librados 的版本要跟 Ceph 的版本对应Debian 9 没有自带与 Ceph Octopusv15.2.*版本匹配的 librados-dev 包因此需要自己下载安装包。安装好 librados-dev 之后就可以开始编译 JuiceFS 客户端。我们这边使用了 Go 1.19 来编译1.19 中新增了控制内存分配最大值https://go.dev/doc/gc-guide#Memory_limit这个特性可以防止极端情况下 JuiceFS 客户端占用过多内存而出现 OOM。make juicefs.ceph复制代码编译完 JuiceFS 客户端即可创建文件系统并在计算节点挂载 JuiceFS 文件系统了详细步骤可以参考 JuiceFS 官方文档。未来和展望JuiceFS 是一款云原生领域的分布式存储系统产品提供了 CSI Driver 组件能够非常好的支持云原生的部署方式在运维部署方面为用户提供了非常灵活的选择用户既可以选择云上也可以选择私有化部署在存储扩容和运维方面较为简单。完全兼容 POSIX 标准以及跟 S3 使用同一套元数据的方式可以非常方便地进行上传、处理、下载的操作流程。由于其后端存储是对象存储的特点在随机小文件读写方面有较高的延迟IOPS 也比较低但在只读场景结合客户端的多级缓存以及大文件场景还有读多写少的场景JuiceFS 有比较大的优势非常契合边缘渲染场景的业务需求。火山引擎边缘云团队未来与 JuiceFS 相关的规划如下更加云原生目前是以 HostPath 的方式来使用 JuiceFS后面我们考虑到一些弹性伸缩的场景可能会切换到以 CSI Driver 的方式来使用 JuiceFS元数据引擎升级抽象一个元数据引擎的 gRPC 服务在其中提供基于多级缓存能力更好地适配读多写少的场景。底层的元数据存储可能会考虑迁移到 TiKV 上以支持更多的文件数量相对于 MySQL 能够更好地通过横向扩展来增加元数据引擎的性能新功能及 bug 修复针对当前业务场景会增加一些功能以及修复一些 bug并期望为社区贡献 PR回馈社区。关于作者何兰州火山引擎边缘计算高级开发工程师负责边缘存储的技术选型演进和稳定性研究领域主要有分布式存储和分布式缓存云原生开源社区爱好者。
