Content provisioning won't be 'free' to Google, as they have to buy/maintain the servers.
buy/maintaining the servers is "free" (or rather, as good as free) if the result of doing so saves sufficiently more money than the price of purchase+maintenance.
I disagree with this. He's already been offered the position and had discussions with HR and his bosses about it. Interviewing and getting competing offers will definitely piss management off. Look at it this way, they have gone out on a limb (from their perspective) to offer this guy an opportunity to become something more than a technical person. [snip]
If the $$$ increase is really/that/ important, and he will be unhappy with his current $$, and he can get an offer for a management job for more than his current $$$, then he should go to the effort of getting the offer, but only if he is prepared to immediately accept the superior offer when he gets it.
Otherwise he would be dishonestly wasting the prospective employer's time and his current employer's time.
Never go to another employer and get a competing offer, that you are not prepared for and will be fully happy accepting.
If he isn't more happy about the offer than his current position, then by definition, it's not a better offer,
and he should not present it for the sole purpose of attempting to persuade a current employer, with the sole exception being that he is so happy with the competing offer he is prepared to accept it immediately, and understanding that it may adversly affect the relationship with his current employer and increase risk to him even if his current employer does match it, he may be canned 3 months later, if his current employer determines he just wasn't worth it.
And the other companies whose offer he did not accept, may be more reluctant to give him an offer again,
so he may reduce his options in regards to seeking a new job.
There are most certainly other options for independent appraisal of value besides a competing offer.
if you can make more money elsewhere, companies want loyal employees.
Employees want loyal companies who won't can them on the spot unfairly.
An employee seeking more compensation, even showing a better offer, is not good cause to can them.
The proper course is to refuse the reasonable request, and it is then the Employee's choice to take the offer
and resign properly, or to accept the best their current employer will offer them.
An employer seeking "more work" from an employee, e.g. Asking them to work 90 hours a week instead of 60,
is also not good cause for the employee to quit on the spot, it is proper for the employee to refuse in such a case,
it is then the Employee's choice to take the offer from a replacement to do the more work for less and inform
the employee properly that they will be terminated, or accept that they cannot get that much extra work from
the employee for the same price, and instead get the most work they can negotiate for the lowest price they can negotiate.
Any sane admin would change the management password when installing the server. And I don't remember any recent vulnerabilities related to ipmi password.
How about, IPMIv1 authentication requires a fixed key of a specific length, and while any sane admin is not going to leave
the Kg_key at 0000000000000000
They may be using the same Kg_key on every server.
They may be using the same username and password on every server.
E.g. a compromise of one server may lead to the hacker dumping the contents of its IPMI RAM
and analyzing it to figure out the administrative credentials common to all the servers
We keep the management network and the production network on separate physical networks. So if you get into a box, you still can't IPMI to any other box.
Are you sure? If you have an IPMI management network, that means your server has at least one connection to this network,
including a physical Ethernet connection that can reach this management network, and an IP address assigned to its own
IPMI service processor.
Who is to say that a hacker can't coopt this server's presence on the IPMI network, and utilize _that_ to gain access to the
IPMI management of other servers?
Are you claiming your IPMI LAN is a routed network, where the network infrastructure outside your server guarantees
that two different servers can never talk to each other?
Journals are only so deep and, more importantly, only contain file metadata.
True, but Volume shadow copy can retain past revisions of files for a considerable length of time.
So can backup applications which store copies of files offline
Whether the client plans to do more business with you in the future or not may be a factor.
You might make a deal where "Your payments for developed software includes 1 year free maintenance to start after implementation, unless you sign up for a longer maintenance contract, or you negotiate new terms with us after 1 year"; you might make a deal where "Any new software project or major upgrade you commission us to perform, will renew your support for existing work, when we receive payment for a certain minimum amount of billable time, and then 1 year after completed implementation of the new project.".
If this was a one-time custom software design job, then provide your client with the source code, provide a contract
or a "warranty" for a reasonable duration that includes bugfixes, and a certain number of minor feature additions they
may request, then beyond that bill based on your costs; If you are a small shop doing custom work , you possibly can't afford to lose a positive referral and future business based on your mistakes; bugs are your mistakes, and you owe it to the customer to make amends for your errors..
However, Every Warranty Has an Expiration Date; if your customer doesn't discover the issue within 6 months, then it's probably reasonable that you didn't discover the issue either, they are just as much at fault for not finding an issue. The companies that offer Lifetime warranties are very big companies mass-producing very simple products that are inexpensive to replace, and Lifetime warranties generally aren't valid once the product goes End of Production / End of Sale anyways.
If your client isn't agreeable to the terms your business needs, eg your customer is just too unreasonable, and you can't come to an arrangement -- don't leave your customer high and dry, either provide them with the source code, or agree to provide source code to a third party software firm they will contract for maintenance (under appropriate NDAs of course).
Obviously your customer is in the wrong expecting perpetual development work for free,
unless you have an ongoing business relationship that is mutually beneficial.
A restaurant may post a "Free Refills" sign by a drink fountain.
That doesn't mean it's reasonable for you to bring your glass home with you, and come by
every morning expecting free refills of the drink you bought last year, for the rest of your life.
Now if you paid $50 for that 8oz soda, perhaps it would be reasonable to expect free refills for
a few days, but still, not forever.
The tech savvy people use bookmarks - or anything more complex than that.
I see tech savvy people typing "Yahoo mail" into Google also.
If it's your home page, you're a decent typist, you don't regularly use Yahoo mail,
and your network connection is reasonable, then typing it in there, is 20% faster than opening up
a bookmarks folder to find it.
A mouse could fall off a building and walk away. People, not so much. The smaller you are, the more resistant you are to long falls.
Close.... the lower your mass to surface volume density; the more resistance you are to long falls.
The most resistant objects to long falls are very large organisms that have very little mass,
and therefore a higher ratio of surface volume to mass.
The larger the object's horizontal cross-section w.r.t the ground, the greater the air resistance, the lower the velocity while falling.
The lower the velocity towards the ground while falling, the lower the change of momentum at the point of impact.
The lower the mass of the object, the lower the change of momentum at the point of impact with the ground.
The lower the change of momentum at the point of impact with the ground, the lower the upward force that is exerted upon the object in the collission.
The difference in damage between the two objects then depends on what the two different objects were constructed from.
Different materials have different strengths; a titanium skeleton will probably fair better than something made out of fired clay.
targeting it just because you can - with all the ensuing civilian casualties - is morally wrong.
No... What's immoral in this case is putting your ammo cache on the top of a hospital, and thereby putting
civilians at direct risk, at risk of enemy action, and at risk of a mishap with the explosives.
The opponent doesn't have any control of the country putting their civillians at risk with irresponsible
placement of military assets.
In war you have to use your manpower efficiently, which means concetrating on targets that are useful
to destroy, and among those, those that are "easiest" or less likely to hurt/reduce your own force in the effort
to destroy targets; Risk/Reward
If the opponent has not surrendered, then they are still fighting, so you are still at war, and still need
to make efforts to undermine their military forces' ability to engage.
Infrastructure and industry was a legitimate target, housing and historical buildings certainly not.
I guess you would say the White House and burning of Washington DC by the British wasn't a legitimate target in the War of 1812? Your assertion's just incorrect.
In a war between nations, anything that provides any value or comfort to your opponent or their citizens is a legitimate target in war, whether that value is direct military asset, or indirect civil/political asset. Historical buildings, social/gathering places, monuments, etc can be suitable targets in their own right if the destruction/loss of those places or things will demoralize the enemy's citizens and thereby reduce their support for the war, or fighting effectiveness.
What kind of building doesn't make a target legit or not.
Any building is potentially a legit target, regardless of its military importance.
Who owns the building, where the building is, who is in the building, or what happens in the building can make it an attractive target.
Politicians know its good to have a boogeyman in your back pocket to scare the electorate
I wouldn't be surprised if the Politicians were getting paid off by the cartels indirectly to keep illegal drugs illegal,
so they don't have the competition to deal with; or there's some "understanding" that they don't mess with the cartels' business, and the politicians' family will be safe.
I hand the whole thing to ZFS before I run out the media wear indicator. The same disk vastly under-provisioned (giving ZFS a 15GB slice) my media wear indicator will last about 4.2PB (yes, 4200TB).
There is no point in getting a 300GB SSD to use as ZIL, because the maximum amount of disk space that ZFS will use on the ZIL is one half of the system's RAM; you would literally need 600GB of RAM, before a 300GB could possibly be utilized as ZIL by ZFS.. It would not be necessary to "slice" or "partition" your oversized SSD to limit the amount of space ZFS would use.
L2ARC is different, but I would recommend you spend the money on the RAM first, get at least 128gb
of RAM, before thinking about buying a 100gb L2ARC, and make sure you scale your CPU power with
the amount of RAM (because Solaris will utilize more CPU under certain circumstances as a
result of having more RAM). The problem for now is that the L2ARC is not persistent,
the L2ARC starts at a blank slate after every system boot, so it has many of the same
disadvantages as RAM, as far as caches go, that cache takes a lot longer than the ARC to warm
up, and it's not that performant.
I understand that ZFS can't send a cache flush to a slice, but if I'm using a SSD with a supercap (say Intel 320) I have never heard any valid argument or reference.
If ZFS cannot send a cache flush for your ZIL device, you must ensure the SSD's write cache is disabled, which is absolutely terrible for both your ZIL performance and for the longevity of the SSD. For that reason and others,
the developers on zfs-discuss have in the past stated that using a log device that is not a dedicated device is a not supported configuration; in response to people who showed such a configuration and indicated they were having some performance problem.
The Solaris documentation for Log and Cache device supports states that L2ARC and ZIL dedicated devices may be utilized. ZIL devices may be mirrored, ZIL devices cannot be RaidZ; mirroring by ZFS alone is the only supported ZIL redundancy. L2ARC devices cannot be mirrored by ZFS. It has never been stated by the documentation that a partition or slice is a supported configuration for ZIL devices, the documentation says dedicated Hard Drive or SSD, which means dedicated hard drive or SSD, not "whatever you like". The ZFS default is that the ZIL resides on the main pool; your main pool can have slices as VDEVs, this is safe on ordinary well-behaved hard drives, because ZFS does not enable any write cache, but administration is complicated by that configuration; SSDs are "special" because many of them enable write cache without permission which is unsafe; it's unsafe to utilize SSD on a disk slice for anything in ZFS, root pool, data pool, etc, without ensuring cache disablement, it's not just use as ZIL that is unsafe with a SSD slice.
It is unsafe to utilize even dedicated SSD devices and other storage devices that do not obey CACHE FLUSH commands properly.
The impact of SSD cache disablement on device longevity and performance is so much so that the value of having a dedicated SSD ZIL goes away; At that point, you would be better off dedicating a mirrored pair of 600gb10kRPM SAS drives for the ZIL and not slicing them up at all, which is less expensive than buying
a pair of 300gb Enterprise SSDs, that's for sure.
The use of a SSD with a supercap is strongly recommended for the ZIL as it will reduce wear, but you need to have a configuration where the caching is safe. If you fail to disable the write cache for the SSD in such a scenario where it's unsafe, what will happen, is that in case of power failure, there is a chance that you will have some data flushed from the previous transaction group and some data flushed from the current one, in other words, your ZIL will be in a state that will cause data loss, and that ZFS cannot recover from automatically, you will be potentially unable to import your pool when you boot back up, and the recovery procedure will be painful, due to the duration of downtime.
Probably most of the "old" people who have chosen "strong passwords" are children under 13 who are lying about their age,
because Yahoo won't let you signup for an e-mail account, you can't trust the demographic data in Yahoo's DB.
"Joseph Bonneau, a computer scientist at the University of Cambridge, calculated the password strengths of nearly 70 million Yahoo! users.
How the hell did a researcher get access to Yahoo's password database?
Why are the passwords not hashed? How come a researcher is able to look at them and
analyze the strength of our passwords?
The passwords by supposed 'age distribution' is of less significance to me.
I don't think Yahoo even knows my correct birthday.
You don't need to partition, you can use/dev/sdb and/dev/sdc instead. My question to you is, is Linux doing something that Solaris doesn't support? ie: Capable of running ZFS in a partition instead of using whole disk?
Solaris is capable of running ZFS on a disk slice, and it's something I will rarely use, but I will use it for the boot media, when running the ZFS boot volume off a CF card, I will mirror it to a small slice on a pair of hard drives, and have another slice on those two drives mirrored for providing the "System log" / scratch disk partition.
What you must never do is utilize a SSD slice for the ZIL. It "works", but can cause problems and has serious consequences regarding data integrity in case of a system crash. Using disk slices is not supported for L2ARC or ZIL, even though nothing technically prevents it, you don't do that.
You can use a disk slice as a VDEV member for a ZFS pool on Solaris, but you lose a number of the benefits of ZFS by doing so, for example: ZFS will no longer be able to turn on writeback buffering for the disk and manage the write cache for the device intelligently, because that means you could have non-ZFS partitions on another slice.
It only makes sense to do that on cryogenically cold partitions, such as system logging/scratch disks, never on mission critical production data datastores.
Define what will make it 'production quality' please.
Production quality means I can safely load mission critical applications on the datastore, in well-understood
hardware configurations, eg disk JBODs attached to a SAS controller, where the application requires 99.9% or better uptime, without risk of getting fired because of that decision, and there are no serious doubts about the integrity of the data, availability, and performance, that are not understood about the filesystem implementation, or integration with the OS
and hardware support regarding the OS combination of the filesystem and certified hardware, all the availability features you expect are there and reliable, such as fault management, IP Multipathing, Storage multipathing, etc; the Solaris ZFS implementation has been used in production for well over 7 years in this case, the ZFSOnLinux implementation is brand new.
In the case of Solaris, the ZFS implementation has proven stability, performance, and track record
for critical applications. I can also implement ZFS in an HA cluster on Solaris with shared storage,
with proper design, there are no serious questions about integrity of my data and availability, that don't have good answers.
ZFS on Solaris might not work right with all choices of hardware, but basically, my data is safe, unless I use reliable components, or I experience hardware faults that exceed the amount of redundancy in the ZFS Pool (e.g. 2 drives fail in a 2-way mirror, 3 drives fail in a raidz2 pool).
I definitely agree NFS on Linux still needs work. Hell, it's still possible to lock up a server if you don't treat NFS just right. But, to be honest, I'd rather see the CIFS support extended more to be honest, mostly better security models offered on it
Solaris + ZFS has a better CIFS implementation than is available on Linux, , but honestly when clients are running Unix, NFS is the better choice. When CIFS is needed, for Windows clients, the only real game in town is Windows 2008 server, for most applications. It's fine for simple file sharing, as long as your requirements are simple -- but when you start running third party database applications, support will blindly blame the CIFS server for its woes and refuse to support the application until its moved, "It's not supported, the share needs to be on a Windows server"
CIFS leaves much to be desired in the security department, whereas NFSv4 can utilize kerberos authentication, and RPSEC-GSS is potentially available; CIFS traffic cannot be encrypted, without tunnelling or IPsec
Ha ha ha. You know part of the magic of ZFS is management of the entire disk drive.
No partitioning
Look: The ZFS on Linux project is a noble effort, and I am sure many Linux users will eventually benefit,
and it will maybe be good enough for them to not switch to Solaris.
But none of this stuff is production quality yet on Linux, and the performance VS Solaris is questionable.
Linux doesn't have the components to implement all the integrations and beneficial "layering violations" ZFS has on Solaris;
and they won't for a long time, Sun spent over 10 years and tens of millions on development of Solaris and their filesystems, I don't think it's reasonable to expect to see the same kind of polish on Linux for ZFS or Dtrace at this point, and we don't;
lots of work and funding could change the situation, but for now the Linux implementation doesn't hold a candle to the Solaris implementation.
You can go ahead and add: COMSTAR, SMF, FMD, and an excellent native NFS server implementation,
to the list of things Solaris has but Linux doesn't.
The Linux implementation of even ZFS is less mature and sheds benefits of ZFS.
Including ease of management. 10 commands just to get setup? Geez.
With Solaris, you have ZFS out of the box and you just do "zpool create tank mirror c1t0d0 c1t1d0 mirror c1t2d0 c1t3d0
No "partitioning" ZFS manages the disks, including disk cache, and fault management.
You can be pretty darn sure zfsonlinux doesn't have the same level of FMA reporting / fault management capabilities.
Really? As part of my job, I manage about 100 physical servers in about 20 countries. I lose about 1 server a month, a figure which is dwarfed by the number of network outages
You just said you lose 1 server a month, hard down, requiring serious repairs. OK. Out of 100 servers, that gives you a 1% chance of losing the vCenter server per month, per year you have 12 times 1%, if the server lost every month is a random selection, that means you have a 60% chance of the vCenter server being impacted after 5 years have passed. Now if you subtracted 33 of those servers, and you have 66 servers organized into clusters of 3 servers. Your chance of losing a server vCenter is hosted on is now ( 1 / 100) * ( 66 / 100) = 0.67% instead of 1%, because you have 2/3 as many servers. Assuming the same average chance per server. Fewer servers = fewer hardware failures.
Your average chance of losing two of 3 servers in one of your HA clusters is half that, because you have to lose two servers during the same month for vCenter to be impacted (assuming your maximum time to repair is less than 30 days). Therefore, after 20 years, you have less than a 10% chance of a vCenter hard failure caused by a double server hardware failure in the same month; that sure as hell beats the 60% chance after 4 years scenario .
You just said 20 countries. When you are extending a network a long distance, it is not surprising that you have more network outages; you also get management problems created by the latency across such great distances.
I would hazard to say that your situation is not typical.
Most small businesses I know of are not global.
When we're talking about clustering with virtualization, we are usually referring to servers in the same room.
I manage over 100 servers in one room. I have seen plenty of hard drive failures, and a few server failures a year; most of them due to software.
Network rarely ever fails. Obviously things will be different if the network is poorly managed, but proper networking design and management is a pre-requisite before you go down the clustering and shared storage route in the first place.
With virtualization and shared storage, a bad network design = possible data corruption, even greater impact, than in a simple network used only for interconnecting PCs and possible servers.
Simpler example, all your virtualization hosts get their address from a mac addrs hard coded DHCP server... And the DHCP server is virtualized. I almost accidentally did this one.
That's true, but most people know to not to use a DHCP server to assign IP addresses to production servers.
Determinism and predictability are important.
Also, VMware recommended we virtualize Vcenter since our cluster is split between two physical locations since those two locations share the same layer 2 networks. This means we can shut down one of the locations without anyone ever noticing.
Sharing the L2 network probably means both sites can fail simultaneously, though; i'm specifically speaking of the possibility of a broadcast storm caused by a bridging loop at one site or a software failure in a switch.
The VI client can be run directly against the host where Vcenter exists to bootstrap the environment, all you have to do is plan ahead for that scenario and test that plan once in a while.
Possibly. But have you tested your bootstrap procedure in realistic circumstances? Do you have a procedure to quickly figure out which host you should connect to directly in order to check on the status of particular VMs required to regain efficient control?
Are you aware that in vSphere5 ESXi, there are some new changes since vSphere4 that severely restrict the functionality you get when you connect directly to a host that has been registered with a vCenter?
For example, if you try to restore a VM from backup directly to the host and enter VM > Edit Settings,
certain changes will give you an error "Access to resource settings on the host is restricted to the server 'aaa.bbb.ccc.ddd' which is managing it".
Examples of such changes are: Changing the storage adapter type, changing some network settings and resource allocation settings, Expanding a Virtual disk (vCenter ran out of disk space; you can't connect directly to a host, expand that, and power vCenter back on, not without resetting the ESXi host back to defaults, and causing it to forget it's vCenter-managed anyways). I guess you'll be OK as long as you don't need to register a new vCenter VM completely or make major changes directly on a host which have been restricted now.
PBX/voicemail servers are also physical, everything else is virtualized.
In general, no problem virtualizing PBXes or voicemail servers. You do realize, Cisco distributes UCM as an OVA now, and Virtualization is a recommended deployment option? No problem with OpenSER, Hylafax, and a few others in a VM either.
One exception I would make is PBXes that require physical hardware, potentially, its better to just make it physical than to futz around with VMDirectPath. Also, use of Asterisk specifically with transcoding or conferencing is a big no-no, because the application utilizes a flawwed system for timing, that has a side effect that also means quality will be unpredictable under virtualization, and especially so with those functions.
Last time I checked the recommendation from VMware was not to use NTP on the VM at all, instead use VMware Tools to sync time with the VMware host and make sure the host itself is synced using NTP.
It is a PITA to attempt to configure VMware Tools Time sync on a Linux VM that has no X installed.
And timekeeping is really not that big an issue in virtualized Windows. In my experience, just make sure to configure your windows AD servers with common physical NTP servers via the w32tm/config command, and the timekeeping is quite reasonable; in fact, so far, i've yet to see VMware timekeeping issues with Windows, all the problems I encountered with VM clocks running too quickly or too slow were Linux VMs, various versions of Debian, and Redhat kernels older than 5.2 are particularly problematic, the special kernel options divider=10 elevator=deadline are still advisable.
Also VMware Tools Time sync will correct the clock if it runs slower than real time -- if the guest OS' clock runs fast, for whatever reason.. VMware Tools will not set the clock "backwards"; it will only advance the clock forwards.
NTP server as a client works fine, if you adjust it appropriately; another thing to consider is cronning a "ntpdat
Let the vendor size out a system that meets your requirements (metrics) without putting stipulations like above in the RFQ. They only cause problems and often eliminate viable options.
Treat the storage like a black box. Come up with an IOPS, bandwidth, and response times and ensure the metrics are hit.
Spoken like a true salesdroid; "Please ignore the man behind the curtain," just trust our performance claims, even when they defy what physics and math says the avg performance should be. The vendor will size out their equipment alright, and they'll be drooling, with their RAID5 solution, knowing full well you'll be coming out with another RFQ within a year to deal with the performance issue, probably requiring you to spend ever increasing amounts of $$$ for more and more cache, because your applications' working set sized up, and it wouldn't have been an issue if your spindle config could actually tackle your average workload on a raw IOPS basis.
IOPS and response times are not all we care about. Performance consistency under ever-varying loads, graceful degradation, component reliability, headroom, extent of degradation in event of failure, cost per performance, cost per capacity unit are important too.
NetApp has cach acceleration but uses RAID-6. They all produce systems to meet enterprise level loads while violating those rules.
NetAPP's product is not RAID6; it's RAID-DP. What they are implementing is definitely not RAID6,
specifically they have implemented a proprietary scheme, and it is only marginally less performant than RAID10.
IBM sells an XIV composed entirely off the shelf components on SATA
And XIV is not a good solution for large performance-critical applications and mixed workloads that require excellent IO response times. You can get decent performance off XIV in the aggregate; but there is a lack of performance consistency, and wide striping gets you in trouble as amount of disk space used increases, unexpected
sudden 20, 30% degradations are never cool.
Specifically, the raw disk performance of the XIV units totally suck compared to a comparable capacity 10kRPM SAS array. Good "Performance" relies entirely on effective caching, and this doesn't work for various busy DB workloads,
cache misses will kill your application.
It's not a good solution if you can use SATA spindles, but you'll require 6 times as many spindles
and a bunch of SSDs, to get average acceptable performance, the cost will be high.
SAS disk drives are more expensive than SATA drives, but not so much more expensive that it is a good
tradeoff to switch to SATA if 3 - 6x the spindles will be required as a result, and 60-70% of the extra
capacity that SATA drives offer must be left unused in order to maintain performance.
For those with an aversion to running a Windows SQL box just for vCenter, try the SuSE/Postgresql based VMWare vCenter Server Appliance.
If it were PostgreSQL, and didn't have so many limitations, VCSA would have been a welcome addition.
Last I checked the VCSA is SuSE + Oracle Express DB, and if you choose an external DB with the VCSA, it has to be IBM DB2 or Oracle; SQL Server is not a supported external db of the VCSA.
With the VCSA Oracle express, you have some significant limitations, just like you have with MS SQL Express.
And my experience with the VCSA is that it has been flaky at best, at least in the initial setup process --
it is presumably more reliable once up and running.
Slashdot Mirror
Content provisioning won't be 'free' to Google, as they have to buy/maintain the servers.
buy/maintaining the servers is "free" (or rather, as good as free) if the result of doing so saves sufficiently more money than the price of purchase+maintenance.
I disagree with this. He's already been offered the position and had discussions with HR and his bosses about it. Interviewing and getting competing offers will definitely piss management off. Look at it this way, they have gone out on a limb (from their perspective) to offer this guy an opportunity to become something more than a technical person. [snip]
If the $$$ increase is really /that/ important, and he will be unhappy with his current $$, and he can get an offer for a management job for more than his current $$$, then he should go to the effort of getting the offer, but only if he is prepared to immediately accept the superior offer when he gets it.
Otherwise he would be dishonestly wasting the prospective employer's time and his current employer's time.
Never go to another employer and get a competing offer, that you are not prepared for and will be fully happy accepting. If he isn't more happy about the offer than his current position, then by definition, it's not a better offer, and he should not present it for the sole purpose of attempting to persuade a current employer, with the sole exception being that he is so happy with the competing offer he is prepared to accept it immediately, and understanding that it may adversly affect the relationship with his current employer and increase risk to him even if his current employer does match it, he may be canned 3 months later, if his current employer determines he just wasn't worth it.
And the other companies whose offer he did not accept, may be more reluctant to give him an offer again, so he may reduce his options in regards to seeking a new job.
There are most certainly other options for independent appraisal of value besides a competing offer.
if you can make more money elsewhere, companies want loyal employees.
Employees want loyal companies who won't can them on the spot unfairly.
An employee seeking more compensation, even showing a better offer, is not good cause to can them. The proper course is to refuse the reasonable request, and it is then the Employee's choice to take the offer and resign properly, or to accept the best their current employer will offer them.
An employer seeking "more work" from an employee, e.g. Asking them to work 90 hours a week instead of 60, is also not good cause for the employee to quit on the spot, it is proper for the employee to refuse in such a case, it is then the Employee's choice to take the offer from a replacement to do the more work for less and inform the employee properly that they will be terminated, or accept that they cannot get that much extra work from the employee for the same price, and instead get the most work they can negotiate for the lowest price they can negotiate.
The thing is... even if it doesn't work out, you have offers. You could actually take the other org up on their offer, you get the $$$ either way.
Any sane admin would change the management password when installing the server. And I don't remember any recent vulnerabilities related to ipmi password.
How about, IPMIv1 authentication requires a fixed key of a specific length, and while any sane admin is not going to leave the Kg_key at 0000000000000000
They may be using the same Kg_key on every server. They may be using the same username and password on every server.
E.g. a compromise of one server may lead to the hacker dumping the contents of its IPMI RAM and analyzing it to figure out the administrative credentials common to all the servers
We keep the management network and the production network on separate physical networks. So if you get into a box, you still can't IPMI to any other box.
Are you sure? If you have an IPMI management network, that means your server has at least one connection to this network, including a physical Ethernet connection that can reach this management network, and an IP address assigned to its own IPMI service processor.
Who is to say that a hacker can't coopt this server's presence on the IPMI network, and utilize _that_ to gain access to the IPMI management of other servers?
Are you claiming your IPMI LAN is a routed network, where the network infrastructure outside your server guarantees that two different servers can never talk to each other?
Journals are only so deep and, more importantly, only contain file metadata.
True, but Volume shadow copy can retain past revisions of files for a considerable length of time. So can backup applications which store copies of files offline
Whether the client plans to do more business with you in the future or not may be a factor. You might make a deal where "Your payments for developed software includes 1 year free maintenance to start after implementation, unless you sign up for a longer maintenance contract, or you negotiate new terms with us after 1 year"; you might make a deal where "Any new software project or major upgrade you commission us to perform, will renew your support for existing work, when we receive payment for a certain minimum amount of billable time, and then 1 year after completed implementation of the new project.".
If this was a one-time custom software design job, then provide your client with the source code, provide a contract or a "warranty" for a reasonable duration that includes bugfixes, and a certain number of minor feature additions they may request, then beyond that bill based on your costs; If you are a small shop doing custom work , you possibly can't afford to lose a positive referral and future business based on your mistakes; bugs are your mistakes, and you owe it to the customer to make amends for your errors..
However, Every Warranty Has an Expiration Date; if your customer doesn't discover the issue within 6 months, then it's probably reasonable that you didn't discover the issue either, they are just as much at fault for not finding an issue. The companies that offer Lifetime warranties are very big companies mass-producing very simple products that are inexpensive to replace, and Lifetime warranties generally aren't valid once the product goes End of Production / End of Sale anyways.
If your client isn't agreeable to the terms your business needs, eg your customer is just too unreasonable, and you can't come to an arrangement -- don't leave your customer high and dry, either provide them with the source code, or agree to provide source code to a third party software firm they will contract for maintenance (under appropriate NDAs of course).
Obviously your customer is in the wrong expecting perpetual development work for free, unless you have an ongoing business relationship that is mutually beneficial.
A restaurant may post a "Free Refills" sign by a drink fountain. That doesn't mean it's reasonable for you to bring your glass home with you, and come by every morning expecting free refills of the drink you bought last year, for the rest of your life.
Now if you paid $50 for that 8oz soda, perhaps it would be reasonable to expect free refills for a few days, but still, not forever.
Can someone explain to me how GTLDs are actually supposed to work?
It's http://tickets./ with a dot at the end.
Otherwise DNS qualification rules for dotless names apply. http://tickets/ refers to (TICKETS).(YOURLOCALDOMAIN).
Also, Host records except nameservers aren't allowed in the root zone.
The tech savvy people use bookmarks - or anything more complex than that.
I see tech savvy people typing "Yahoo mail" into Google also. If it's your home page, you're a decent typist, you don't regularly use Yahoo mail, and your network connection is reasonable, then typing it in there, is 20% faster than opening up a bookmarks folder to find it.
We know nobody will be bothering registering subdomains on these turds.
Fine then... I call dibs on SPEEDING.TICKETS
A mouse could fall off a building and walk away. People, not so much. The smaller you are, the more resistant you are to long falls.
Close.... the lower your mass to surface volume density; the more resistance you are to long falls.
The most resistant objects to long falls are very large organisms that have very little mass, and therefore a higher ratio of surface volume to mass.
The larger the object's horizontal cross-section w.r.t the ground, the greater the air resistance, the lower the velocity while falling.
The lower the velocity towards the ground while falling, the lower the change of momentum at the point of impact.
The lower the mass of the object, the lower the change of momentum at the point of impact with the ground.
The lower the change of momentum at the point of impact with the ground, the lower the upward force that is exerted upon the object in the collission.
The difference in damage between the two objects then depends on what the two different objects were constructed from. Different materials have different strengths; a titanium skeleton will probably fair better than something made out of fired clay.
targeting it just because you can - with all the ensuing civilian casualties - is morally wrong.
No... What's immoral in this case is putting your ammo cache on the top of a hospital, and thereby putting civilians at direct risk, at risk of enemy action, and at risk of a mishap with the explosives. The opponent doesn't have any control of the country putting their civillians at risk with irresponsible placement of military assets.
In war you have to use your manpower efficiently, which means concetrating on targets that are useful to destroy, and among those, those that are "easiest" or less likely to hurt/reduce your own force in the effort to destroy targets; Risk/Reward
If the opponent has not surrendered, then they are still fighting, so you are still at war, and still need to make efforts to undermine their military forces' ability to engage.
Infrastructure and industry was a legitimate target, housing and historical buildings certainly not.
I guess you would say the White House and burning of Washington DC by the British wasn't a legitimate target in the War of 1812? Your assertion's just incorrect.
In a war between nations, anything that provides any value or comfort to your opponent or their citizens is a legitimate target in war, whether that value is direct military asset, or indirect civil/political asset. Historical buildings, social/gathering places, monuments, etc can be suitable targets in their own right if the destruction/loss of those places or things will demoralize the enemy's citizens and thereby reduce their support for the war, or fighting effectiveness.
What kind of building doesn't make a target legit or not. Any building is potentially a legit target, regardless of its military importance. Who owns the building, where the building is, who is in the building, or what happens in the building can make it an attractive target.
Politicians know its good to have a boogeyman in your back pocket to scare the electorate
I wouldn't be surprised if the Politicians were getting paid off by the cartels indirectly to keep illegal drugs illegal, so they don't have the competition to deal with; or there's some "understanding" that they don't mess with the cartels' business, and the politicians' family will be safe.
I hand the whole thing to ZFS before I run out the media wear indicator. The same disk vastly under-provisioned (giving ZFS a 15GB slice) my media wear indicator will last about 4.2PB (yes, 4200TB).
There is no point in getting a 300GB SSD to use as ZIL, because the maximum amount of disk space that ZFS will use on the ZIL is one half of the system's RAM; you would literally need 600GB of RAM, before a 300GB could possibly be utilized as ZIL by ZFS.. It would not be necessary to "slice" or "partition" your oversized SSD to limit the amount of space ZFS would use.
L2ARC is different, but I would recommend you spend the money on the RAM first, get at least 128gb of RAM, before thinking about buying a 100gb L2ARC, and make sure you scale your CPU power with the amount of RAM (because Solaris will utilize more CPU under certain circumstances as a result of having more RAM). The problem for now is that the L2ARC is not persistent, the L2ARC starts at a blank slate after every system boot, so it has many of the same disadvantages as RAM, as far as caches go, that cache takes a lot longer than the ARC to warm up, and it's not that performant.
I understand that ZFS can't send a cache flush to a slice, but if I'm using a SSD with a supercap (say Intel 320) I have never heard any valid argument or reference.
If ZFS cannot send a cache flush for your ZIL device, you must ensure the SSD's write cache is disabled, which is absolutely terrible for both your ZIL performance and for the longevity of the SSD. For that reason and others, the developers on zfs-discuss have in the past stated that using a log device that is not a dedicated device is a not supported configuration; in response to people who showed such a configuration and indicated they were having some performance problem.
The Solaris documentation for Log and Cache device supports states that L2ARC and ZIL dedicated devices may be utilized. ZIL devices may be mirrored, ZIL devices cannot be RaidZ; mirroring by ZFS alone is the only supported ZIL redundancy. L2ARC devices cannot be mirrored by ZFS. It has never been stated by the documentation that a partition or slice is a supported configuration for ZIL devices, the documentation says dedicated Hard Drive or SSD, which means dedicated hard drive or SSD, not "whatever you like". The ZFS default is that the ZIL resides on the main pool; your main pool can have slices as VDEVs, this is safe on ordinary well-behaved hard drives, because ZFS does not enable any write cache, but administration is complicated by that configuration; SSDs are "special" because many of them enable write cache without permission which is unsafe; it's unsafe to utilize SSD on a disk slice for anything in ZFS, root pool, data pool, etc, without ensuring cache disablement, it's not just use as ZIL that is unsafe with a SSD slice.
It is unsafe to utilize even dedicated SSD devices and other storage devices that do not obey CACHE FLUSH commands properly.
The impact of SSD cache disablement on device longevity and performance is so much so that the value of having a dedicated SSD ZIL goes away; At that point, you would be better off dedicating a mirrored pair of 600gb10kRPM SAS drives for the ZIL and not slicing them up at all, which is less expensive than buying a pair of 300gb Enterprise SSDs, that's for sure.
The use of a SSD with a supercap is strongly recommended for the ZIL as it will reduce wear, but you need to have a configuration where the caching is safe. If you fail to disable the write cache for the SSD in such a scenario where it's unsafe, what will happen, is that in case of power failure, there is a chance that you will have some data flushed from the previous transaction group and some data flushed from the current one, in other words, your ZIL will be in a state that will cause data loss, and that ZFS cannot recover from automatically, you will be potentially unable to import your pool when you boot back up, and the recovery procedure will be painful, due to the duration of downtime.
Probably most of the "old" people who have chosen "strong passwords" are children under 13 who are lying about their age, because Yahoo won't let you signup for an e-mail account, you can't trust the demographic data in Yahoo's DB.
"Joseph Bonneau, a computer scientist at the University of Cambridge, calculated the password strengths of nearly 70 million Yahoo! users.
How the hell did a researcher get access to Yahoo's password database?
Why are the passwords not hashed? How come a researcher is able to look at them and analyze the strength of our passwords?
The passwords by supposed 'age distribution' is of less significance to me. I don't think Yahoo even knows my correct birthday.
You don't need to partition, you can use /dev/sdb and /dev/sdc instead. My question to you is, is Linux doing something that Solaris doesn't support? ie: Capable of running ZFS in a partition instead of using whole disk?
Solaris is capable of running ZFS on a disk slice, and it's something I will rarely use, but I will use it for the boot media, when running the ZFS boot volume off a CF card, I will mirror it to a small slice on a pair of hard drives, and have another slice on those two drives mirrored for providing the "System log" / scratch disk partition.
What you must never do is utilize a SSD slice for the ZIL. It "works", but can cause problems and has serious consequences regarding data integrity in case of a system crash. Using disk slices is not supported for L2ARC or ZIL, even though nothing technically prevents it, you don't do that.
You can use a disk slice as a VDEV member for a ZFS pool on Solaris, but you lose a number of the benefits of ZFS by doing so, for example: ZFS will no longer be able to turn on writeback buffering for the disk and manage the write cache for the device intelligently, because that means you could have non-ZFS partitions on another slice.
It only makes sense to do that on cryogenically cold partitions, such as system logging/scratch disks, never on mission critical production data datastores.
Define what will make it 'production quality' please.
Production quality means I can safely load mission critical applications on the datastore, in well-understood hardware configurations, eg disk JBODs attached to a SAS controller, where the application requires 99.9% or better uptime, without risk of getting fired because of that decision, and there are no serious doubts about the integrity of the data, availability, and performance, that are not understood about the filesystem implementation, or integration with the OS and hardware support regarding the OS combination of the filesystem and certified hardware, all the availability features you expect are there and reliable, such as fault management, IP Multipathing, Storage multipathing, etc; the Solaris ZFS implementation has been used in production for well over 7 years in this case, the ZFSOnLinux implementation is brand new.
In the case of Solaris, the ZFS implementation has proven stability, performance, and track record for critical applications. I can also implement ZFS in an HA cluster on Solaris with shared storage, with proper design, there are no serious questions about integrity of my data and availability, that don't have good answers.
ZFS on Solaris might not work right with all choices of hardware, but basically, my data is safe, unless I use reliable components, or I experience hardware faults that exceed the amount of redundancy in the ZFS Pool (e.g. 2 drives fail in a 2-way mirror, 3 drives fail in a raidz2 pool).
I definitely agree NFS on Linux still needs work. Hell, it's still possible to lock up a server if you don't treat NFS just right. But, to be honest, I'd rather see the CIFS support extended more to be honest, mostly better security models offered on it
Solaris + ZFS has a better CIFS implementation than is available on Linux, , but honestly when clients are running Unix, NFS is the better choice. When CIFS is needed, for Windows clients, the only real game in town is Windows 2008 server, for most applications. It's fine for simple file sharing, as long as your requirements are simple -- but when you start running third party database applications, support will blindly blame the CIFS server for its woes and refuse to support the application until its moved, "It's not supported, the share needs to be on a Windows server"
CIFS leaves much to be desired in the security department, whereas NFSv4 can utilize kerberos authentication, and RPSEC-GSS is potentially available; CIFS traffic cannot be encrypted, without tunnelling or IPsec
3) Partition the new drives.
)9 .... “sudo zpool create zfs-blog raidz /dev/sdb1 /dev/sdc1”
Ha ha ha. You know part of the magic of ZFS is management of the entire disk drive. No partitioning
Look: The ZFS on Linux project is a noble effort, and I am sure many Linux users will eventually benefit, and it will maybe be good enough for them to not switch to Solaris.
But none of this stuff is production quality yet on Linux, and the performance VS Solaris is questionable. Linux doesn't have the components to implement all the integrations and beneficial "layering violations" ZFS has on Solaris; and they won't for a long time, Sun spent over 10 years and tens of millions on development of Solaris and their filesystems, I don't think it's reasonable to expect to see the same kind of polish on Linux for ZFS or Dtrace at this point, and we don't; lots of work and funding could change the situation, but for now the Linux implementation doesn't hold a candle to the Solaris implementation.
You can go ahead and add: COMSTAR, SMF, FMD, and an excellent native NFS server implementation, to the list of things Solaris has but Linux doesn't.
The Linux implementation of even ZFS is less mature and sheds benefits of ZFS. Including ease of management. 10 commands just to get setup? Geez.
With Solaris, you have ZFS out of the box and you just do "zpool create tank mirror c1t0d0 c1t1d0 mirror c1t2d0 c1t3d0
No "partitioning" ZFS manages the disks, including disk cache, and fault management.
You can be pretty darn sure zfsonlinux doesn't have the same level of FMA reporting / fault management capabilities.
Really? As part of my job, I manage about 100 physical servers in about 20 countries. I lose about 1 server a month, a figure which is dwarfed by the number of network outages
You just said you lose 1 server a month, hard down, requiring serious repairs. OK. Out of 100 servers, that gives you a 1% chance of losing the vCenter server per month, per year you have 12 times 1%, if the server lost every month is a random selection, that means you have a 60% chance of the vCenter server being impacted after 5 years have passed. Now if you subtracted 33 of those servers, and you have 66 servers organized into clusters of 3 servers. Your chance of losing a server vCenter is hosted on is now ( 1 / 100) * ( 66 / 100) = 0.67% instead of 1%, because you have 2/3 as many servers. Assuming the same average chance per server. Fewer servers = fewer hardware failures.
Your average chance of losing two of 3 servers in one of your HA clusters is half that, because you have to lose two servers during the same month for vCenter to be impacted (assuming your maximum time to repair is less than 30 days). Therefore, after 20 years, you have less than a 10% chance of a vCenter hard failure caused by a double server hardware failure in the same month; that sure as hell beats the 60% chance after 4 years scenario .
You just said 20 countries. When you are extending a network a long distance, it is not surprising that you have more network outages; you also get management problems created by the latency across such great distances.
I would hazard to say that your situation is not typical. Most small businesses I know of are not global.
When we're talking about clustering with virtualization, we are usually referring to servers in the same room.
I manage over 100 servers in one room. I have seen plenty of hard drive failures, and a few server failures a year; most of them due to software. Network rarely ever fails. Obviously things will be different if the network is poorly managed, but proper networking design and management is a pre-requisite before you go down the clustering and shared storage route in the first place.
With virtualization and shared storage, a bad network design = possible data corruption, even greater impact, than in a simple network used only for interconnecting PCs and possible servers.
Simpler example, all your virtualization hosts get their address from a mac addrs hard coded DHCP server... And the DHCP server is virtualized. I almost accidentally did this one.
That's true, but most people know to not to use a DHCP server to assign IP addresses to production servers. Determinism and predictability are important.
Also, VMware recommended we virtualize Vcenter since our cluster is split between two physical locations since those two locations share the same layer 2 networks. This means we can shut down one of the locations without anyone ever noticing.
Sharing the L2 network probably means both sites can fail simultaneously, though; i'm specifically speaking of the possibility of a broadcast storm caused by a bridging loop at one site or a software failure in a switch.
The VI client can be run directly against the host where Vcenter exists to bootstrap the environment, all you have to do is plan ahead for that scenario and test that plan once in a while.
Possibly. But have you tested your bootstrap procedure in realistic circumstances? Do you have a procedure to quickly figure out which host you should connect to directly in order to check on the status of particular VMs required to regain efficient control?
Are you aware that in vSphere5 ESXi, there are some new changes since vSphere4 that severely restrict the functionality you get when you connect directly to a host that has been registered with a vCenter?
For example, if you try to restore a VM from backup directly to the host and enter VM > Edit Settings, certain changes will give you an error "Access to resource settings on the host is restricted to the server 'aaa.bbb.ccc.ddd' which is managing it". Examples of such changes are: Changing the storage adapter type, changing some network settings and resource allocation settings, Expanding a Virtual disk (vCenter ran out of disk space; you can't connect directly to a host, expand that, and power vCenter back on, not without resetting the ESXi host back to defaults, and causing it to forget it's vCenter-managed anyways). I guess you'll be OK as long as you don't need to register a new vCenter VM completely or make major changes directly on a host which have been restricted now.
PBX/voicemail servers are also physical, everything else is virtualized.
In general, no problem virtualizing PBXes or voicemail servers. You do realize, Cisco distributes UCM as an OVA now, and Virtualization is a recommended deployment option? No problem with OpenSER, Hylafax, and a few others in a VM either.
One exception I would make is PBXes that require physical hardware, potentially, its better to just make it physical than to futz around with VMDirectPath. Also, use of Asterisk specifically with transcoding or conferencing is a big no-no, because the application utilizes a flawwed system for timing, that has a side effect that also means quality will be unpredictable under virtualization, and especially so with those functions.
Last time I checked the recommendation from VMware was not to use NTP on the VM at all, instead use VMware Tools to sync time with the VMware host and make sure the host itself is synced using NTP.
It is a PITA to attempt to configure VMware Tools Time sync on a Linux VM that has no X installed. And timekeeping is really not that big an issue in virtualized Windows. In my experience, just make sure to configure your windows AD servers with common physical NTP servers via the w32tm /config command, and the timekeeping is quite reasonable; in fact, so far, i've yet to see VMware timekeeping issues with Windows, all the problems I encountered with VM clocks running too quickly or too slow were Linux VMs, various versions of Debian, and Redhat kernels older than 5.2 are particularly problematic, the special kernel options divider=10 elevator=deadline are still advisable.
Also VMware Tools Time sync will correct the clock if it runs slower than real time -- if the guest OS' clock runs fast, for whatever reason.. VMware Tools will not set the clock "backwards"; it will only advance the clock forwards.
NTP server as a client works fine, if you adjust it appropriately; another thing to consider is cronning a "ntpdat
Let the vendor size out a system that meets your requirements (metrics) without putting stipulations like above in the RFQ. They only cause problems and often eliminate viable options.
Treat the storage like a black box. Come up with an IOPS, bandwidth, and response times and ensure the metrics are hit.
Spoken like a true salesdroid; "Please ignore the man behind the curtain," just trust our performance claims, even when they defy what physics and math says the avg performance should be. The vendor will size out their equipment alright, and they'll be drooling, with their RAID5 solution, knowing full well you'll be coming out with another RFQ within a year to deal with the performance issue, probably requiring you to spend ever increasing amounts of $$$ for more and more cache, because your applications' working set sized up, and it wouldn't have been an issue if your spindle config could actually tackle your average workload on a raw IOPS basis.
IOPS and response times are not all we care about. Performance consistency under ever-varying loads, graceful degradation, component reliability, headroom, extent of degradation in event of failure, cost per performance, cost per capacity unit are important too.
NetApp has cach acceleration but uses RAID-6. They all produce systems to meet enterprise level loads while violating those rules.
NetAPP's product is not RAID6; it's RAID-DP. What they are implementing is definitely not RAID6, specifically they have implemented a proprietary scheme, and it is only marginally less performant than RAID10.
IBM sells an XIV composed entirely off the shelf components on SATA
And XIV is not a good solution for large performance-critical applications and mixed workloads that require excellent IO response times. You can get decent performance off XIV in the aggregate; but there is a lack of performance consistency, and wide striping gets you in trouble as amount of disk space used increases, unexpected sudden 20, 30% degradations are never cool.
Specifically, the raw disk performance of the XIV units totally suck compared to a comparable capacity 10kRPM SAS array. Good "Performance" relies entirely on effective caching, and this doesn't work for various busy DB workloads, cache misses will kill your application.
It's not a good solution if you can use SATA spindles, but you'll require 6 times as many spindles and a bunch of SSDs, to get average acceptable performance, the cost will be high.
SAS disk drives are more expensive than SATA drives, but not so much more expensive that it is a good tradeoff to switch to SATA if 3 - 6x the spindles will be required as a result, and 60-70% of the extra capacity that SATA drives offer must be left unused in order to maintain performance.
For those with an aversion to running a Windows SQL box just for vCenter, try the SuSE/Postgresql based VMWare vCenter Server Appliance.
If it were PostgreSQL, and didn't have so many limitations, VCSA would have been a welcome addition. Last I checked the VCSA is SuSE + Oracle Express DB, and if you choose an external DB with the VCSA, it has to be IBM DB2 or Oracle; SQL Server is not a supported external db of the VCSA. With the VCSA Oracle express, you have some significant limitations, just like you have with MS SQL Express.
And my experience with the VCSA is that it has been flaky at best, at least in the initial setup process -- it is presumably more reliable once up and running.
I have seen the time on virtual machines hopping around -- even those that are running ntpd.
The local clock cannot be disciplined. Configure ntpd to not use the local clock as a time source.
Or use vmware tools time sync, that is preferred.
Don't try to virtualize NTP time servers, it's unreliable.