| Thanks Yehuda very much for the response.
In theory you could have either, however, the preferred mode of
installation is with having FastCgiExternalServer and manually running
the radosgw.
How many radosgw daemons should be launched in such case, should it equal to the number of httpd processes?
Besides, it looks like a documentation issue on this page: http://ceph.com/docs/master/install/rpm/, it recommends using FastCgiExternalServer, however, it does not mention that part that radosgw application should be manually launched (maybe I am new to fastcgi though).
Thanks, Guang On Sep 24, 2013, at 10:51 PM, Yehuda Sadeh wrote: On Tue, Sep 24, 2013 at 12:46 AM, Guang < yguang11@xxxxxxxxx> wrote: Hi ceph-users,
I deployed a Ceph cluster (including RadosGW) with use of ceph-deploy on
RHEL6.4, during the deployment, I have a couple of questions which need your
help.
1. I followed the steps http://ceph.com/docs/master/install/rpm/ to deploy
the RadosGW node, however, after the deployment, all requests failed with
500 returned. With some hints from
http://irclogs.ceph.widodh.nl/index.php?date=2013-01-25, I changed the
FastCgiExternalServer to FastCgiServer within rgw.conf. Is this change valid
or I missed somewhere else which leads the need for this change?
In theory you could have either, however, the preferred mode of installation is with having FastCgiExternalServer and manually running the radosgw.
2. It still does not work and the httpd has the following error log:
[Mon Sep 23 07:34:32 2013] [crit] (98)Address already in use: FastCGI:
can't create server "/var/www/s3gw.fcgi": bind() failed [/tmp/radosgw.sock]
which indicates that radosgw is not started properly, so that I manually run
"radosgw --rgw-socket-path=/tmp/radosgw.sock -c /etc/ceph/ceph.conf -n
client.radosgw.gateway" to start a radosgw daemon and then the gateway
starts working as expected.
Did I miss anything this part?
That's one way to run the radosgw process. You still want to change the apache conf to use the external server configuration, otherwise apache will try relaunch it.
3. When I was trying to run ceph admin-daemon command on the radosGW host,
it failed because it does not have the corresponding asok file, however, I
am able to run the command on monitor host and found that the radosGW's
information can be retrieved there.
@monitor (monitor and gateway are deployed on different hosts).
[xxx@startbart ceph]$ sudo ceph --admin-daemon
/var/run/ceph/ceph-mon.startbart.asok config show | grep rgw
"rgw": "1\/5",
"rgw_data": "\/var\/lib\/ceph\/radosgw\/ceph-startbart",
"rgw_enable_apis": "s3, swift, swift_auth, admin",
"rgw_cache_enabled": "true",
"rgw_cache_lru_size": "10000",
"rgw_socket_path": "",
"rgw_host": "",
"rgw_port": "",
"rgw_dns_name": "",
"rgw_script_uri": "",
"rgw_request_uri": "",
"rgw_swift_url": "",
"rgw_swift_url_prefix": "swift",
"rgw_swift_auth_url": "",
"rgw_swift_auth_entry": "auth",
"rgw_keystone_url": "",
"rgw_keystone_admin_token": "",
"rgw_keystone_accepted_roles": "Member, admin",
"rgw_keystone_token_cache_size": "10000",
"rgw_keystone_revocation_interval": "900",
"rgw_admin_entry": "admin",
"rgw_enforce_swift_acls": "true",
"rgw_swift_token_expiration": "86400",
"rgw_print_continue": "true",
"rgw_remote_addr_param": "REMOTE_ADDR",
"rgw_op_thread_timeout": "600",
"rgw_op_thread_suicide_timeout": "0",
"rgw_thread_pool_size": "100",
Is this expected?
The ceph configuration is monolithic, you see the mon configuration here, and there are some rgw defaults, but it doesn't reflect the actual rgw configuration. There's an open issue for gateway not creating the admin socket by default, try adding 'admin socket' config line to your gateway ceph.conf.
4. cephx authentication. After reading through the cephx introduction, I got
the feeling that cephx is for client to cluster authentication, so that each
librados user will need to create a new key. However, this page
http://ceph.com/docs/master/rados/operations/authentication/#enabling-cephx
got me confused in terms of why should we create keys for mon and osd? And
how does that fit into the authentication diagram? BTW, I found the keyrings
under /var/lib/cecph/{role}/ for each roles, are they being used when talk
to other roles?
cephx is a kerberos-like authentication, and each entity needs to have a key. In a distributed system like ceph, there's no single 'server' (as in client-server). There could be many thousands of such servers, and we want to authenticate each and one of them. That been said, when a client gets a service ticket, it gets it for all services of the same type, so it doesn't need to acquire a new ticket for each osd it connects to. Yehuda
|
