Posted by _-. on May 11, 2011 at 4:40pm
our current web stack is an all IPv4, DIY implementation of,
nginx
multiple listeners on IPv4:80, IPv4:443
proxypass to varnish-cache on 127.0.0.1:9000
|
|
varnish-cache
listener on 127.0.0.1:9000
filter/pass to 'faux-CDN' on Apache2
'img' -> 127.0.0.1:12003
'css' -> 127.0.0.1:12002
'js' -> 127.0.0.1:12001
'...' -> 127.0.0.1:12000
|
|
apache2/mod_php,mod_deflate +
Pressflow6/memcached(cache_inc/session_inc/lock_inc)
listeners/vhosts on 127.0.0.1:1200{0,1,2,3}
all works as planned.
we're now adding IPv6 listeners on assigned AAAA records @ each nginx "server {..." for dual-stack operation,
nginx - multiple listeners on IPv4:80, IPv4:443 +- multiple listeners on IPv4/IPv6:80, IPv4/IPv6:443
questions:
what other parts in the stack need to change to accommodate IPv6 and keep caching, Pressflow, etc working?
does each after-nginx component need a mirrored/parallel IPv6-only instance?
or, simply add IPv6 listeners to the current IPv4 listeners?
or, leave it all alone, depending only on the nginx proxy pass to correctly hand-off to the chain, regardless of the inbound address family, -6 or -4?
Comments
May I suggest you post this
May I suggest you post this to the nginx group? You're probably more likely to get an answer there.
The Boise Drupal Guy!
thanks.moved to:
thanks.
moved to: http://groups.drupal.org/node/149049
update:
[ it's rather quiet "over there" too, so, if the spirit moves anyone to comment here -- as this is a not un-common Pressflow stack ... ]
AFAIK there is nothing that
AFAIK there is nothing that needs to be done within Drupal / Pressflow.
http://drupal.org/project/issues/search/drupal?issue_tags=ipv6
ip_address is always treated as a string and it's always stored large enough to accommodate an IPv6 address. The only place something could go wrong is if some module uses ip2long() which only handles IPv4 addresses. Caching (within Drupal) should not be affected as neither ip_address or hostname are involved in determining cache keys.
I think Varnish should be fine as well.
If in doubt, give it a go and so some manual testing.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
AFAIK there is nothing that
Drupal's support for IPv6 itself was clear -- when listening on IPv6. I'm not clear yet in this 'stack' what to do with two "entry points" at the nginx front end, namely IPv4 & IPv6. Do I need to pass inbound IPv6 traffic to a Drupal/Apache instance (or Varnish in between, for that matter), that's listening on IPv6? Basically, I'm trying to understand if I need two parallel stacks -- one for each AddressFamily's ingress.
ok
noted, and something I can look for. thanks.
There's the info that should make a difference -- no ip/hostname used. I think that implies a single stack behind the two ingress points is (??) sufficient, and that it'd not matter if the stack components are listening on IPv4 or 6. "all" IPv4 or "all" IPv6 is clear as a bell. Mixed environment, still confusing.
completely, still.
That presumes I fully understand what I'm seeing in those tests ;-) Getting there ...
AFAIK there is nothing that
Drupal's support for IPv6 itself was clear -- when listening on IPv6. I'm not clear yet in this 'stack' what to do with two "entry points" at the nginx front end, namely IPv4 & IPv6. Do I need to pass inbound IPv6 traffic to a Drupal/Apache instance (or Varnish in between, for that matter), that's listening on IPv6? Basically, I'm trying to understand if I need two parallel stacks -- one for each AddressFamily's ingress.
ok
noted, and something I can look for. thanks.
There's the info that should make a difference -- no ip/hostname used. I think that implies a single stack behind the two ingress points is (??) sufficient, and that it'd not matter if the stack components are listening on IPv4 or 6. "all" IPv4 or "all" IPv6 is clear as a bell. Mixed environment, still confusing.
completely, still.
That presumes I fully understand what I'm seeing in those tests ;-) Getting there ...
Caching
In regards to caching the cache_get and cache_set Cache API functions use arbitrary cache keys. These can be any string, and I've never seen so far an IP address used as a cache key. Where you might want to peek into is the settings.php. Drupal's default persistent cache mechanism is the database. This requires no IP configuration other than the database connection string found in the settings.php. However if you are using a pluggable caching mechanism with Drupal such as memcached (which is also configured in settings.php), you might want to double-check the IP addresses and ports specified in settings.php, and that they are compatible with the IPv6 protocol. Likewise, you might want to research whether Memcached can be set up to support both IPv4 and 6, or only version 4.
In regards to Varnish their issue queue might provide some clues as to the current support for IPv6. Section 3.2.1 of their spec says that Varnish should support IPv6, but I have no idea if the current release is there or not. I'd find that if I were in your position. Since I think an answer to this question would benefit everyone inside and outside the Drupal community, I have taken the liberty to ask these questions on servefault.com. Does Varnish support IPv6?. Does Memcached support IPv6?
good points, thanks. re:
good points, thanks.
re: memcached, in my settings.php, i've,
$conf['reverse_proxy'] = TRUE;
$conf['reverse_proxy_addresses'] = array('127.0.0.1');
$conf['cache_inc'] = './sites/all/modules/memcache/memcache.inc';
$conf['session_inc'] = './sites/all/modules/memcache/memcache-session.inc';
$conf['lock_inc'] = './sites/all/modules/memcache/memcache-lock.inc';
$conf['memcache_servers'] = array('127.0.0.1:10001' => 'default',);
$conf['memcache_bins'] = array('cache' => 'default',);
$conf['memcache_key_prefix'] = 'dev';
re: its IPv6 support, a statement @:
http://dev.mysql.com/doc/refman/5.0/en/ha-memcached-using.html
"Support for IPv6 address support was added in memcached 1.2.5"
& a long thread @:
http://www.mail-archive.com/memcached@lists.danga.com/msg02324.html
"The attached patch does the following:
1) Adds support for binding with host names (not just ip addresses)
2) Makes memcached support IPv6 for TCP connections.
Attachment: ipv6.patch"
suggest yes, but there seems to be no mention of IPv6 on memcached's wiki :-/ and, this
http://groups.google.com/group/memcached/search?q=ipv6&start=0&scoring=d&
seems to indicate ongoing discussion ... i.e., dunno.
in Varnish current, in the example ./redhat/varnish.sysconfig,
## Default address and port to bind to
## Blank address means all IPv4 and IPv6 interfaces, otherwise specify
## a host name, an IPv4 dotted quad, or an IPv6 address in brackets.
# VARNISH_LISTEN_ADDRESS=
VARNISH_LISTEN_PORT=6081
so, seems yes.
that said, still dunno what to actually implement in the stack ...
fwiw, re: varnish, comments @
fwiw, re: varnish, comments @ varnish list verify that varnish can concurrently listen on IPv4 & IPv6.
tho, as to what do do with the whole_stack, as being discussed here, the answer's a bit less informative,
"What you set up is up to you.
...
What Varnish should and shouldn't do in this regards is up to you, not Varnish, since Varnish is happy either way."
so, pending on memcached clarity.
even though varnish is verified as CAN listen on both, how to set up Drupal/Apache on the backend -- IPv4 &/or IPv6
i'm certain others run a similar nginx->varnish->drupal/apache stack, as well as using other cache/frontend/backend mixes. here's hoping to hear from someone that also is working on adding IPv6 to the mix. as you've said, others will benefit as well.
In regards to caching the
This is true, but in practice it's customary to prefix the key name with the name of the module which primarily manages it, just as with Drupal variables. So the "foo" module, if it follows this custom, will cache things with keys like "foo_bar" or "foo_baz_qux".
The Boise Drupal Guy!