Re: VMware Training

2014-02-20 Thread Dan Shoop

[See below]

On Feb 19, 2014, at 10:46 PM, Jay Ashworth j...@baylink.com wrote:

 Why bother with a clustering FS, then, if you cannot actually /use it/ as one?
 - jra
 
 On February 19, 2014 10:44:22 PM EST, Jimmy Hess mysi...@gmail.com wrote:
 On Wed, Feb 19, 2014 at 2:06 PM, Jay Ashworth j...@baylink.com wrote:
 
 - Original Message -
 From: Eugeniu Patrascu eu...@imacandi.net
 [snip]
 My understanding of cluster-aware filesystem was can be mounted at
 the
 physical block level by multiple operating system instances with
 complete
 safety.  That seems to conflict with what you suggest, Eugeniu; am I
 missing something (as I often do)?
 
 
 When one of the hosts has a virtual disk file open for write access on
 a
 VMFS cluster-aware filesystem,it is locked to that particular host,
 and  a process on a different host is denied the ability write to the
 file,   or even open the file for read access.

Ghods how I miss real tightly coupled clustering, shared hierarchical storage 
and true clustered filesystems like in VMS. Here’s a 35 year old OS that still 
is better than anything we have today. Secure, granular prigs, file versioning, 
multiple simultaneous cluster interconnect physical layers, POSIX compliance, 
heavy distributed networking and strong system services built in. When people 
tell me about clustering today and then add these caveats about how clustered 
files aren’t actually sharable or that you can’t have complete orthogonality. 

I guess I’m now old. 

-d 

-

Dan Shoop
sh...@iwiring.net
1-646-402-5293 (GoogleVoice)







Re: VMware Training

2014-02-20 Thread Dan Shoop

On Feb 20, 2014, at 1:48 PM, Jimmy Hess mysi...@gmail.com wrote:

 The locking restrictions are for your own protection. If the filesystem
 inside your virtual disks is not a clustered filesystem;
 two instances of a VM  simultaneously  mounting the same NTFS volume and
 writing some things, is an absolute disaster.
 
 
 Under normal circumstances,  two applications should never be writing to
 the same file.  This is true on clustered filesystems.
 This is true when running multiple applications on a single computer.

Why should two applications should never be writing to the same file? In a 
real clustered *file*system this is exactly what you want. The same logical 
volume mounted across host cluster members, perhaps geodistantly located, each 
having access at the record level to the data. This permits HA and for the 
application to be distributed across cluster nodes. If a host node is lost then 
the application stays running. If the physical volume is unavailable then 
logically shadowing the volume across node members or storage controllers / 
SANs permits fault tolerance. You don’t need to “fail disks over” (really 
logical volumes) as they are resilient from the start, they just don’t fail. 
When the shadow members return they replay journals or resilver if the journals 
are lost. 

I’d note that this can be accomplished just so long as you have a common disk 
format across the OS nodes. 

These problems were all resolved 40 years ago in mainframe and supermini 
systems. They’re not new. VMware has been slowly reinventing — more accurately 
rediscovering — well known HA techniques as it’s trying to mature. And it still 
has a lot of catching up to do. It’s the same tale that microcomputers have 
been doing for decades as they’ve come into use as servers. 

However I’m not sure what all of this has to do with network operations. ;)



-d 

-

Dan Shoop
sh...@iwiring.net
1-646-402-5293 (GoogleVoice)







Re: NTP DRDos Blog post

2014-02-20 Thread Dan Shoop

On Feb 20, 2014, at 11:43 AM, Jon Lewis jle...@lewis.org wrote:

 On Thu, 20 Feb 2014, Brian Rak wrote:
 
 That's not a new term.
 
 http://en.wikipedia.org/wiki/DRDOS
 DRDoS, a type of network attack named Distributed Reflection Denial of 
 Service.
 http://en.wikipedia.org/wiki/Distributed_Reflection_Denial_of_Service#Reflected_.2F_Spoofed_attack
 
 Or Digital Research Disk Operating System...if you're old enough.
 Who knew DRDOS would become popular [again]?

I had wondered what the problem was, older than age, with anyone trying to run 
DRDOS. It should fit in the memory and cpu footprint of a modern toaster. 

-d 

-

Dan Shoop
sh...@iwiring.net
1-646-402-5293 (GoogleVoice)







Re: comcast business service

2014-02-20 Thread Dan Shoop

On Feb 20, 2014, at 4:08 AM, shawn wilson ag4ve...@gmail.com wrote:

 A while ago I got Comcast's business service. Semi-idle connections
 are get dropped (I haven't really diagnosed this - I just no that it
 isn't the client or server but some network in between). However the
 second and most obvious issue is that intermittently, the service will
 grind to a halt:
 --- 8.8.8.8 ping statistics ---
 37 packets transmitted, 34 received, 8% packet loss, time 36263ms
 rtt min/avg/max/mdev = 398.821/5989.160/14407.055/3808.068 ms, pipe 15
 
 After a modem reboot, it goes normal:
 --- 8.8.8.8 ping statistics ---
 4 packets transmitted, 4 received, 0% packet loss, time 3003ms
 rtt min/avg/max/mdev = 23.181/23.920/24.298/0.474 ms
 
 This seems to happen about once or twice a day. I can't attribute it
 to any type of traffic or number of connections. All of the rest of
 the network equipment is the same and the behavior persists when a
 computer is plugged directly into the modem. I called Comcast and they
 said they didn't see anything even when I was experiencing ridiculous
 ping times. I tend to think it's an issue with the 'modem' but I'm not
 sure what the issue might be or how to reproduce it when asked to if I
 tell them to look at it.

I’ve seen this happen before with various cable ISPs. I’d concur with the 
poster suggesting intermittent noise on the cable segment as a likely culprit. 
Also if you have a cable modem that binds multiple channels for higher 
bandwidth this can also be problematic, especially with the noise. Signals will 
look good to the NOC but it’s not the signal “level that’s the issue it’s the 
signal to noise level. Noise has to be measured locally and techs don’t always 
check SNL. 

Also check to see if the packets aren’t actually being dropped but just taking 
longer than ping is looking for. Also check for out of sequence packets 
returned. These can indicate flapping of a bonded circuit or the bonded circuit 
experiencing noise. Try seeing if you disconnect everything and get a straight 
run to the demarc, with a know and tested out good cable, if the problem 
doesn’t ever occur. This could indicate noise on the cable in your premise. But 
I’ve experienced this same problem with noise coming through the demarc. I’ve 
also seen levels too hot beyond the demarc causing similar problems too. 

HTH.


-d 

-

Dan Shoop
sh...@iwiring.net
1-646-402-5293 (GoogleVoice)