Hi All,
I'm attempting to devise a method which will provide continuous operation of
certain resources in the event of a disaster at a single facility.
The types of resources that need to be available in the event of a disaster are
ecommerce applications and other business critical resources.
On Jun 3, 2009, at 7:09 PM, Drew Weaver wrote:
What is the best way to handle the routing? Obviously two devices
cannot occupy the same IP address at the same time, so how do you
provide that instant 'cut-over'?
Avoid 'cut-over' entirely - go active/active/etc., and use DNS-based
GSLB f
Drew,
IMO as your %Availability goes up, (99, 99.9, 99.99.100%)... your
price to implement will go up exponentially. That being said, a
majority of this will depend on what your budget is to achieve your
desired availability.
You can either
- Failover to backup servers using DNS (but may no
On the subject of DNS GSLB, there's a fairly well known article on the subject
that anyone considering implementing it should read at least once :)
http://www.tenereillo.com/GSLBPageOfShame.htm
and part 2
http://www.tenereillo.com/GSLBPageOfShameII.htm
Yes it was written in 2004. But all t
On Wed, Jun 3, 2009 at 8:09 AM, Drew Weaver wrote:
> I'm attempting to devise a method which will provide continuous
>operation of certain resources in the event of a disaster at a single facility.
Drew,
If you can afford it, stretch the LAN across the facilities via fiber
and rebuild the critica
gb10hkzo-na...@yahoo.co.uk writes:
> On the subject of DNS GSLB, there's a fairly well known article on the
> subject that anyone considering implementing it should read at least
> once :)
>
> http://www.tenereillo.com/GSLBPageOfShame.htm
> and part 2
> http://www.tenereillo.com/GSLBPageOfSham
On Wed, Jun 3, 2009 at 9:37 AM, William Herrin wrote:
> On Wed, Jun 3, 2009 at 8:09 AM, Drew Weaver wrote:
>
>
>
> If you can't afford the fiber or need to put the DR site too far away
> for fiber to be practical, you can still build a network which
> virtualizes your LAN. However, you then hav
As with all things, there's no "right answer" . a lot of it depends on
three things :
- what you are hoping to achieve
- what your budget is
- what you have at your disposal in terms of numbers of qualified staff
available to both implement and support the chosen solution
That's the main b
On Wed, Jun 3, 2009 at 7:09 AM, Drew Weaver wrote:
> Hi All,
>
> I'm attempting to devise a method which will provide continuous operation
> of certain resources in the event of a disaster at a single facility.
>
> The types of resources that need to be available in the event of a disaster
> are
On Jun 3, 2009, at 9:37 PM, William Herrin wrote:
If you can afford it, stretch the LAN across the facilities via fiber
and rebuild the critical services as a load balanced active-active
cluster.
I would advise strongly against stretching a layer-2 topology across
sites, if at all possible
On Wed, Jun 3, 2009 at 10:53 AM, wrote:
> - whether you are after an active/active or active/passive solution
In practice, active/passive DR solutions often fail. You rarely need
to fail over to the passive system. When you finally do need to fail
over, there are a dozen configuration changes tha
Tell me about it .. "failover test what failover test" ;-)
- Original Message
From: William Herrin
To: gb10hkzo-na...@yahoo.co.uk
Cc: nanog@nanog.org
Sent: Wednesday, 3 June, 2009 16:05:15
Subject: Re: Facility wide DR/Continuity
On Wed, Jun 3, 2009 at 10:53 AM, wrote:
> -
On Jun 3, 2009, at 10:05 PM, William Herrin wrote:
You rarely need to fail over to the passive system.
And management will never, ever let you do a full-up test, nor will
they allow you to spend the money to build a scaled-up system which
can handle the full load, because they can't stan
And the Saga continues. We had issues reaching Taiwan through ATT today and
no issues if i flip the outbound traffic through Verizon. I called and
opened ticket with ATT and it seems like they dont want to help or even look
into the issue, its really getting frustrating. These intermittent issues
w
to whoever said ...
>F5's if you like commercial solutions
F5s if you like expensive commercial solutions .
Those with a less bulging wallet may wish to speak to the guys at Zeus
Technology (http://www.zeus.com/) who have a lot of experience in the area and
a more reasonable price tag.
C
(by the way before the accusations start flying of spamming , no I don't
work for Zeus or have any incentive to mention their name... just happen to
know their product)
On Wed, Jun 3, 2009 at 11:15 AM, Roland Dobbins wrote:
> Active/passive is an obsolete 35-year-old mainframe paradigm, and it
> deserves to die the death. With modern technology, there's just really no
> excuse not to go active/active, IMHO.
Roland,
Sometimes you're limited by the need to use ap
Roland Dobbins wrote:
>
> On Jun 3, 2009, at 10:05 PM, William Herrin wrote:
>
>> You rarely need to fail over to the passive system.
>
>
> And management will never, ever let you do a full-up test, nor will they
> allow you to spend the money to build a scaled-up system which can
> handle the
On Jun 3, 2009, at 10:36 PM, William Herrin wrote:
Sometimes you're limited by the need to use applications which aren't
capable of running on more than one server at a time.
All understood - which is why it's important that app devs/database
folks/sysadmins are all part of the virtual team
On Jun 3, 2009, at 10:38 PM, Seth Mattinen wrote:
Some things just don't active/active nicely on a budget.
Sure, because of inefficient legacy design choices.
Distribution and scale is ultimately an application architecture
issue, with networking and ancillary technologies playing an impo
Some things just don't active/active nicely on a budget.
> Sure, because of inefficient legacy design choices.
Roland,
I'm not sure I understand your argument here.
Budget is very much an issue when choosing between active/active and
active/passive. Nothing to do with "inefficient legacy
On Jun 3, 2009, at 11:15 PM, gb10hkzo-na...@yahoo.co.uk wrote:
For example, consider the licensing and hardware costs involved in
running something like Oracle Database in active/active mode (in a
topology that is supported by Oracle Tech Support).
In my experience, it's no more expensive
On Wed, 3 Jun 2009, Drew Weaver wrote:
> Should the additional sites be connected to the primary site
> (and/or the Internet directly)?
Yes, because any out-of-band synchronization method between the servers at
the production site and the servers at the DR site is likely to be more
On Wed, Jun 3, 2009 at 12:47 PM, Bill Woodcock wrote:
> On Wed, 3 Jun 2009, Drew Weaver wrote:
>> Should the additional sites be connected to the primary site
>> (and/or the Internet directly)?
>
> Yes, because any out-of-band synchronization method between the servers at
> the produ
On Jun 4, 2009, at 12:53 AM, Brandon Galbraith wrote:
Or you use RFC1918 address space at each location, and NAT each side
between
public anycasted space and your private IP space. Prevents internal IP
conflicts, having to deal with site to site NAT, etc.
With all due respect, both of these
On Thu, 4 Jun 2009, Roland Dobbins wrote:
> With all due respect, both of these posited choices are quite ugly and
> tend to lead to huge operational difficulties, susceptibility to DDoS,
> etc. Definitely not recommended except as a last resort in a difficult
> situation, IM
Does anyone know how to get in touch with someone at Verizon Wireless
regarding SMTP? Part of our network seems to be blocked by their MX
servers for verizonwireless.com and I can't find any contact info.
Thanks,
Mark
Interesting. I've been dealing with this exact problem for a couple of weeks
now. Several of our DNS servers, but not all, can not resolve an MX for
vtext.com or vtext.biz. Still don't have a resolution and I'm still wading
through their support staff trying to find someone with a clue.
-BB O
Please let me know if you find any clue. The problem I'm having is we
can connect to their incoming mail server but it just throws a reject
error code with no other info:
# telnet mars.verizonwireless.com 25
Trying 162.115.163.69...
Connected to mars.verizonwireless.com (162.115.163.69).
Escape c
We have good results carrying >1492 packets across 6524s running both
ZU2 and SXI1.
I do consider ZU2 to be broken though (ghost route issue). SXI1 behaves
well for us.
adam.
We use Cisco 6524s with packets up to 1546 bytes with no issues. IOS
ZU2, but we are testing SXI1 with no MTU issues
30 matches
Mail list logo
