You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This feature adds to RGW the ability to securely cache objects and offload the workload from the cluster, using Nginx.
10
10
After an object is accessed the first time it will be stored in the Nginx cache directory.
11
11
When data is already cached, it need not be fetched from RGW. A permission check will be made against RGW to ensure the requesting user has access.
12
-
This feature is based on some Nginx modules, ngx_http_auth_request_module, https://github.com/kaltura/nginx-aws-auth-module, Openresty for Lua capabilities.
12
+
This feature is based on the Nginx modules ``ngx_http_auth_request_module`` and `nginx-aws-auth-module <https://github.com/kaltura/nginx-aws-auth-module>`_, and OpenResty for Lua capabilities.
13
13
14
-
Currently, this feature will cache only AWSv4 requests (only s3 requests), caching-in the output of the 1st GET request
15
-
and caching-out on subsequent GET requests, passing thru transparently PUT,POST,HEAD,DELETE and COPY requests.
14
+
Currently this feature will cache only AWSv4 requests (only S3 requests), caching-in the output of the first GET request
15
+
and caching-out on subsequent GET requests, passing through transparently PUT,POST,HEAD,DELETE and COPY requests.
16
16
17
17
18
18
The feature introduces 2 new APIs: Auth and Cache.
19
19
20
-
NOTE: The `D3N RGW Data Cache`_ is an alternative data caching mechanism implemented natively in the RADOS Gateway.
20
+
.. note:: The `D3N RGW Data Cache`_ is an alternative data caching mechanism implemented natively in the RADOS Gateway.
21
21
22
22
New APIs
23
-
-------------------------
23
+
--------
24
24
25
25
There are 2 new APIs for this feature:
26
26
27
-
Auth API - The cache uses this to validate that a user can access the cached data
28
-
29
-
Cache API - Adds the ability to override securely Range header, that way Nginx can use it is own smart cache on top of S3:
Using this API gives the ability to read ahead objects when clients asking a specific range from the object.
32
-
On subsequent accesses to the cached object, Nginx will satisfy requests for already-cached ranges from the cache. Uncached ranges will be read from RGW (and cached).
27
+
- **Auth API:** The cache uses this to validate that a user can access the cached data.
28
+
- **Cache API:** Adds the ability to override securely ``Range`` header so that Nginx can use its own `smart cache <https://www.nginx.com/blog/smart-efficient-byte-range-caching-nginx/>`_ on top of S3.
29
+
Using this API gives the ability to read ahead objects when client is asking a specific range from the object.
30
+
On subsequent accesses to the cached object, Nginx will satisfy requests for already-cached ranges from the cache. Uncached ranges will be read from RGW (and cached).
33
31
34
32
Auth API
35
-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
33
+
~~~~~~~~
36
34
37
-
This API Validates a specific authenticated access being made to the cache, using RGW's knowledge of the client credentials and stored access policy.
35
+
This API validates a specific authenticated access being made to the cache, using RGW's knowledge of the client credentials and stored access policy.
38
36
Returns success if the encapsulated request would be granted.
39
37
40
38
Cache API
41
-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39
+
~~~~~~~~~
42
40
43
-
This API is meant to allow changing signed Range headers using a privileged user, cache user.
41
+
This API is meant to allow changing signed ``Range`` headers using a privileged cache user.
44
42
45
-
Creating cache user
43
+
Creating the cache user:
46
44
47
-
::
45
+
.. prompt:: bash #
46
+
47
+
radosgw-admin user create --uid=<uid for cache user> --display-name="cache user" --caps="amz-cache=read"
48
+
49
+
This user can send to the RGW the Cache API header ``X-Amz-Cache``. This header contains the headers from the original request (before changing the ``Range`` header):
48
50
49
-
$ radosgw-admin user create --uid=<uid for cache user> --display-name="cache user" --caps="amz-cache=read"
51
+
- Original headers are separated from each other by a character with ASCII code 177 decimal.
52
+
- Each original header and its value are separated by a character with ASCII code 178 decimal.
50
53
51
-
This user can send to the RGW the Cache API header ``X-Amz-Cache``, this header contains the headers from the original request(before changing the Range header).
52
-
It means that ``X-Amz-Cache`` built from several headers.
53
-
The headers that are building the ``X-Amz-Cache`` header are separated by char with ASCII code 177 and the header name and value are separated by char ASCII code 178.
54
-
The RGW will check that the cache user is an authorized user and if it is a cache user,
55
-
if yes it will use the ``X-Amz-Cache`` to revalidate that the user has permissions, using the headers from the X-Amz-Cache.
56
-
During this flow, the RGW will override the Range header.
54
+
The RGW will check that the user is an authorized user and that the value is a cache user.
55
+
If both checks succeed it will use the ``X-Amz-Cache`` to revalidate that the user has permissions, using the original headers stored in the ``X-Amz-Cache`` header.
56
+
During this flow the RGW will override the ``Range`` header.
|It is important to substitute the *access key* and *secret key* located in the ``nginx.conf`` file with those belonging to the user with the ``amz-cache`` caps.
118
+
|For example, create the cache user as follows:
125
119
126
-
It is possible to use Nginx slicing which is a better method for streaming purposes.
120
+
.. prompt:: bash #
127
121
128
-
For using slice you should use `nginx-slicing.conf` and not `nginx-default.conf`
It is possible to use `Nginx slicing<https://docs.nginx.com/nginx/admin-guide/content-cache/content-caching/#byte-range-caching>`_ which is suitable for streaming purposes.
To enable slicing you should use ``nginx-slicing.conf`` instead of ``nginx-default.conf``.
133
127
134
128
135
-
If you do not want to use the prefetch caching, It is possible to replace `nginx-default.conf` with `nginx-noprefetch.conf`
136
-
Using `noprefetch` means that if the client is sending range request of 0-4095 and then 0-4096 Nginx will cache those requests separately, So it will need to fetch those requests twice.
129
+
If you do not want to use prefetch caching, it is possible to replace ``nginx-default.conf`` with ``nginx-noprefetch.conf``.
130
+
If prefetch caching is disabled Nginx will cache each range request separately and possible overlap in the range requests will be fetched more than once. For example, if a client is sending a range request of 0-4095 and then 0-4096 both requests are fetched completely from RGW.
137
131
138
132
139
-
Run Nginx(openresty):
133
+
Run Nginx (OpenResty):
140
134
141
-
::
135
+
.. prompt:: bash #
142
136
143
-
$ sudo systemctl restart nginx
137
+
systemctl restart nginx
144
138
145
139
Appendix
146
-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
147
-
**A note about performance:** In certain instances like development environment, disabling the authentication by commenting the following line in `nginx-default.conf`:
140
+
--------
141
+
142
+
**A note about performance:** In certain instances such as a development environment, disabling authentication may (depending on the hardware) increase performance significantly as it forgoes auth API calls to RADOS Gateway.
143
+
This can be done by commenting the following line in ``nginx-default.conf``:
148
144
149
145
::
150
146
151
147
#auth_request /authentication;
152
148
153
-
may (depending on the hardware) increases the performance significantly as it forgoes the auth API calls to radosgw.
0 commit comments