ceph

RadosGW分析。 一、RadosGW的main()函数解析。 RadosGW的main()函数位于rgw_main.cc中，该函数是RadosGW的入口函数。这里主要解析和RadosGW相关的内容，尽量省略WebServer的内容。 main()函数解析如下： 1、根据g_conf->rgw_frontends得到默认支持的前端WebServers，目前默认支持的前端WebServer包括fastcgi和civetweb。对于每一个支持的前端都有一个RGWFrontendConfig类与之对应，最后将WebServer的名字和对应的RGWFrontendConfig类设置到fe_map集合中； 2、调用global_init()函数做初始化操作； 3、调用rgw_tool_init()函数从g_conf->rgw_mime_type_file指定的文件中读取该文件中的数据并初始化； 4、调用curl_global_init()函数初始化libcurl，由此可以看出rgw使用curl进行网络数据传输； 5、调用FCGX_Init()初始化WebServer； 6、调用RGWStoreManager::get_storage()函数初始化librados对象，即：以后对Ceph集群的操作都得通过该librados对象； 7、调用rgw_rest_init()初始化rest部分； 8

RGW ACL主要类关系图如下图所示： RGW ACL处理类关系图如下图所示： RGW ACL主要处理流程详细说明如下。 一、PUT ACL。 RGWPutACL::execute() |__从HTTP请求数据流中解析出RGWAccessControlPolicy_S3对象 |__RGWAccessControlPolicy_S3::rebuild() |__rgw_get_user_info_by_uid() 得到指定的用户信息 |__创建ACLOwner对象且设置ACLOwner的id和name |__遍历grant_map列表生成新的ACLGrant对象 |__将新生成的ACLGrant对象插入到RGWAccessControlList::grant_map中 |__根据bucket和object信息生成rgw_obj对象 |__对于设置对象的ACL则将对象的ACL信息写入到对象属性的RGW_ATTR_ACL中，对于设置bucket的ACL则将ACL信息写入到Bucket的metadata中 二、GET ACL。 RGWGetACLs::execute() |__判断所需是bucket ACL还是object ACL |__生成RGWAccessControlPolicy_S3对象 |__RGWAccessControlPolicy_S3::to_xml()

截止到目前为止，RGW S3的认证部分支持AWS v4认证、AWS v2认证以及匿名用户认证。这三种认证的总入口位于rgw_process.cc::process_request()函数，该函数中处理认证部分的代码如下： rgw_process.cc::process_request() |__RGW_Auth_S3::authorize() |__根据HTTP请求参数决定认证方式（AWS v4/AWS v2/匿名认证） 下面分别描述这三种认证方式： 1、AWS v2认证方式。 AWS v2认证由RGW_Auth_S3::authorize_v2()函数处理。使用AWS v2方式认证，用户首现根据用户的secret key对认证头部数据进行签名操作，与此同时将认证头部数据、签名数据、用户的access key信息加入到HTTP请求数据流中。RGW收到HTTP请求数据流后提取出上述信息，之后通过用户的access key获取到用户信息（user info）。之后使用用户信息中的secret key对HTTP请求数据流中的认证头部数据进行签名操作，最后判断由RGW计算出来的签名值是否与HTTP请求数据流中的签名值一致来实现用户的认证。 AWS v2函数处理流程如下： RGW_Auth_S3::authorize() |__通过HTTP请求数据流得到用户的access key

一、list bucket。 1、读取bucket信息处理流程。 RGWListBucket::execute() |__RGWRados::Bucket::List::list_objects() |__RGWRados::cls_bucket_list() |__RGWRados::open_bucket_index() |__CLSRGWIssueBucketList::issue_op() |__issue_bucket_list_op() |__librados::IoCtxImpl::aio_operate() op is rgw.bucket_list |__cls_rgw.cc::rgw_bucket_list() |__cls_rgw.cc::read_bucket_header() 读取struct rgw_bucket_dir的header信息 |__cls_rgw.cc::get_obj_vals() 读取struct rgw_bucket_dir的entry信息 |__将读取到的struct rgw_bucket_dir信息转换成RGWObjEnt结构 |__检查读取到的RGWObjEnt结构的合法性 实际保存到ceph集群中bucket信息的数据结构是struct rgw_bucket_dir，该结构内容如下： Struct rgw_bucket_dir

一、RGW S3 CORS核心类关系图。 二、RGW S3 CORS处理类关系图。 三、RGW S3 CORS操作解析。 1、PUT CORS操作。 RGWPutCORS::execute() |__RGWPutCORS_ObjStore_S3::get_params() |__从HTTP请求数据流中找到CORSConfiguration域并转换成RGWCORSConfiguration_S3对象 |__RGWCORSConfiguration_S3::encode() 序列化RGWCORSConfiguration_S3对象 |__对于设置对象的CORS则 |__RGWRados::get_bucket_instance_obj() 得到待设置CORS属性的object信息 |__RGWRados::set_attrs() 设置CORS属性到object的属性列表中且以RGW_ATTR_CORS作为索引 |__对于设置bucket的CORS则 |__rgw_bucket_set_attrs() 设置CORS属性到bucket的属性列表中且以RGW_ATTR_CORS作为索引 2、GET CORS操作。 RGWGetCORS::execute() |__RGWOp::read_bucket_cors() |__获取指定bucket的RGW_ATTR_CORS属性值 |_

一、安装wireshark wireshark从2.0版开始支持ceph协议解析 下载地址： https://www.wireshark.org/download/ 二、ceph网络抓包 使用tcpdump在ceph集群上抓包，e.g.：tcpdump -i ens33 -s 0 -w 3ceph.pcap host 172.16.134.95 and host 172.16.134.96 ， ens33是网络接口名字，3ceph.pcap是保存的抓包的文件名字，host 172.16.134.95 and host 172.16.134.96是在这两个节点之间流动的数据包 注意：tcpdump抓包要从ceph集群会话开始抓，否则在会话中间抓包，wireshark不识别。 三、wireshark架构 1、GUI处理在页面上所有用户的显示包块对话框，源码在ui/qt下面 2、core主要的“胶水”模块，把别的模块整合到一起，源码在根目录下 3、Epan包分析引擎，用协议书的形式分析包。源码在 epan目录下 4、Wiretap用于读、写捕获的文件，源码在wiretap目录下 5、Capture捕获网络数据的接口模块，源码在capture下 参考： https://www.wireshark.org/docs/wsdg_html_chunked/ChWorksOverview.html

安装 root@:~# wget -q -O- 'https://download.ceph.com/keys/release.asc' | sudo apt-key add - root@:~# echo deb http://download.ceph.com/debian-luminous/ $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list root@:~# apt-get update && apt-get upgrade root@:~# apt-get install ceph-mds ceph 部署mon 两台机器都部署mon: a、b mon.a 配置： [global] max open files = 131072 fsid = a7f64266-0894-4f1e-a635-d0aeaca0e993 auth cluster required = cephx auth service required = cephx auth client required = cephx osd pool default size = 3 osd pool default min size = 2 osd pool default pg num = 1024 osd pool

作者 | 李鹏（壮怀） 阿里云智能事业群高级技术专家 导读 ：新的企业负载／智能工作负载容器化、迁云、存储方面遇到的性能、弹性、高可用、加密、隔离、可观测性以及生命周期等方面的问题，不但需要存储产品层次的改进，更需要在云原生的控制／数据平面的改进，推进云原生存储和云存储的演进。本文将介绍一下问题场景，探讨可行的解决方案，最终得出云原生存储以及云存储目前可以做什么和未来还需要做什么。 引言 最近有幸参加了由 Infra Meetup 联合 Kubernetes & Cloud Native Meetup 共同组织的面向云原生持久化应用的 Meetup，结合最近对云存储、开源存储、云原生存储的思考，对云原生存储到底是什么，需要做些什么，云原生存储未来挑战是什么，做了更多的反思和梳理，一家之言，分享了几个初步观点。 随着云原生应用对可迁移性、扩展性和动态特性的需求，相应的，对云原生存储也带来了密度、速度、混合度的要求，所以对云存储基本能力又提出了在效率、弹性、自治、稳定、应用低耦合、GuestOS 优化、安全等方面的诉求。 云原生现状 容器和云原生计算被企业快速接纳 Forrester 预测：到 2022 年， 全球组织／公司在生成环境运行容器化应用，从今天不足 30% 的比例将大幅度提升到超过 75%，企业应用容器化的趋势势不可挡。 另一方面，根据 IDC

Rook( https://rook.io )已经到了0.8版本，并且进入CNCF的孵化器。Rook是一个容器存储框架，已经率先支持Ceph( http://docs.ceph.org.cn/start/intro/ )分布式文件系统。 这里介绍其安装过程，其中的Ceph Dashboard也已经可以用了，只不过遇到了一些问题，经过网上四处寻觅，也找到了一个暂时的解决办法。 下载项目文件 执行下面的命令来下载Rook项目源码： git clone https://github.com/rook/rook/ cd cluster/examples/kubernetes/ceph 其中cluster下面的charts/rook-ceph是支持helm的安装文件，不过最近几个月没有更新，不建议使用。可以使用cluster/examples/kubernetes/ceph下面的安装文件，更新一些。该目录下的文件包括： cluster.yaml Ceph集群部署，部署到rook-ceph命名空间。 dashboard-external.yaml 信息面板，提供外部服务的NodePort方式访问。 ec-filesystem.yaml ec-storageclass.yaml filesystem.yaml 文件系统支持。 kube-registry.yaml object.yaml 对象存储