BSD and virtualisation

[CaptainBlame]

The whole 1 service 1 OS trend is completely retarded, we can thank Windows instability in the early days for this line of thinking. It's not just wasting resources, its also administration overhead looking after so many instances.

Really this is what a scheduler is for, to handle multiple workloads, and also in AIX we have a work load manager which was inherited from mainframe. This really should be ported to all systems.

Virtualisation layers doesn't benefit moving hardware, I can take my BSD install and put it on new hardware of the same architecture and it will work.

[revhed]

Originally Posted by flain

Yes but it is such a big benefit.

Cloud isn't such a magic fluffy word like it used to be, it's real now. There are services and products out there that allow you to extend your infrastructure to the cloud, dynamically spin up new server instances as load increases and dynamically deprovision them when load decreases. There are products/services that automate the entire thing based on load, user count, etc which is very attractive to big business right now, and will be for small business too as it gets more and more affordable. The VM performance tax is shrinking too with newer tech like SRIOV, VT, directed IO etc. There isn't as much of a overhead performance hit these days like there used to be.

This is all well and good if you have the bandwidth to access the cloud at reasonable speeds. Here we struggle to get decent speeds by ADSL1 standards if we can even get ADSL at all. I shudder at the thought of accessing cloud based services through dialup Then there is the question of control over your data. What is your mitigation strategy for your cloud service provider denies you access to your data (for whatever reason). I believe businesses are way too "laissez-faire" when it comes to giving control of their data away.

Originally Posted by CaptainBlame

The whole 1 service 1 OS trend is completely retarded, we can thank Windows instability in the early days for this line of thinking. It's not just wasting resources, its also administration overhead looking after so many instances.

Really this is what a scheduler is for, to handle multiple workloads, and also in AIX we have a work load manager which was inherited from mainframe. This really should be ported to all systems.

Virtualisation layers doesn't benefit moving hardware, I can take my BSD install and put it on new hardware of the same architecture and it will work.

It's funny, but I always found windows to be OK with a little TLC from a knowledgeable admin . It was blamed for being unstable an awful lot more than was actually the case - usually by lazy software devs! I found one product relativly recently to be downgrading files that were updated with a windows security patch!

In Windows there are ways to move between hardware also - but with virtualised windows installations especially, it has dumbed it right down

[CaptainBlame]

Originally Posted by revhed

It's funny, but I always found windows to be OK with a little TLC from a knowledgeable admin .

The problem is that knowledge is short lived because the next version of Windows requires a whole bunch of different knowledge.

I feel sorry for the Windows guys, they spend so much time studying MCSE etc and its made obsolete in a few years. All that work and they earn half a Unix admins pay.

[DavidRa]

Originally Posted by CaptainBlame

The whole 1 service 1 OS trend is completely retarded, we can thank Windows instability in the early days for this line of thinking. It's not just wasting resources, its also administration overhead looking after so many instances.

Really this is what a scheduler is for, to handle multiple workloads, and also in AIX we have a work load manager which was inherited from mainframe. This really should be ported to all systems.

Virtualisation layers doesn't benefit moving hardware, I can take my BSD install and put it on new hardware of the same architecture and it will work.

Actually one of the key advantages of "1 app, 1 system" you seem to ignore is the ability to patch the applications separately, and know they are supported and don't interfere with each other.

For a very much contrived example consider a FBSD system hosting some simple services. Let's assume the server must offer BIND for DNS and ... I dunno ... VSFTPd for an FTP server. You need the update to the latest version of BIND for the security updates, and you're already running the latest version of VSFTPd for the same reason.

Except that the latest version of BIND was built against /usr/local/lib/lib_xxy_sso.lib version 4.14j, and won't run against an earlier version; while VSFTPd requires 4.14d or prior due to unintentional use of a side-effect of one of the library calls in /usr/local/lib/lib_xxy_sso.lib.

Without virtualisation, or similar tech (I think jails can work to satisfy this) how do you plan to get both apps working? I'm no FBSD expert but I don't recall any easily portable method to rewrite the load path for a shared library.

[revhed]

Originally Posted by DavidRa

Actually one of the key advantages of "1 app, 1 system" you seem to ignore is the ability to patch the applications separately, and know they are supported and don't interfere with each other.

I don't think he's saying it should be "one OS to rule them all". As administrators we should be making intelligent decisions about what services we pair together to get the most from the hardware. The limitation I constantly see reached with servers these days is Disk IO. Another instance of an OS in not a nil-cost proposition (no matter which camp you subscribe to). If you have a good reason for seperating the services then great, but virtualisaion for virtualisation sake is pretty silly.

[Gecko]

Originally Posted by DavidRa

Actually one of the key advantages of "1 app, 1 system" you seem to ignore is the ability to patch the applications separately, and know they are supported and don't interfere with each other.

I love virtualisation for this. We used to have the monolithic boxes with a billion and one different apps running on them. If you ever needed a reboot, it was virtually impossible to do without impacting on someone. We've split a lot up (not quite 1 app, 1 system, but close to it in places), which makes management a lot easier. It also means that a failure is (generally) contained to a smaller part of the overall infrastructure. Paired with your choice of management tool (puppet, cfengine etc), the management overhead of having more systems running is almost zero.

The primary benefits for us are:

1. Any hardware failures can be dealt with in the middle of business hours, live migrate the VMs to another node, do whatever needs to be done to the broken node, bring it back online and migrate the VMs back to it. No downtime and much better than coming in on a Sunday afternoon to replace parts.
2. Better utilisation of hardware without having 200 different services residing on one OS installation.

[CaptainBlame]

Originally Posted by DavidRa

Actually one of the key advantages of "1 app, 1 system" you seem to ignore is the ability to patch the applications separately, and know they are supported and don't interfere with each other.

Shared libraries have version numbers for this reason. If the app doesn't support symbol versioning, you know you can use library paths?

I don't know about Linux, but this is a non issue in FreeBSD. Perhaps use a better OS.

[elvis]

Originally Posted by CaptainBlame

The whole 1 service 1 OS trend is completely retarded

Sometimes it's beyond our control, like when account managers dictate that two particular customers aren't allowed on the same instance for political reasons, or when your security guys want to minimise the risk of full OS patching.

Not all technical decisions are made by technical people, sadly.

Originally Posted by CaptainBlame

Shared libraries have version numbers for this reason. If the app doesn't support symbol versioning, you know you can use library paths?

I don't know about Linux, but this is a non issue in FreeBSD. Perhaps use a better OS.

And sometimes it's not about the OS, but about the app running on the OS. "Ideal" setups and apps frequently don't exist, and poor app programming plagues every good sysadmin trying to build the perfect environment.

[CaptainBlame]

True there is nothing one can do if management ties your hands with bad decisions. However the OP however is talking about his home server, so I'm talking about doing things the right way.

[DaveQB]

Ran into this article: http://www.packtpub.com/article/secu...-freebsd-jails

With this intro:

FreeBSD Jails are a kernel-level security mechanism which allows you to safely segregate processes within a sandbox environment. Jails are commonly used to secure production network services like DNS or Email by restricting what a process can access. In the case of a malicious attack on one service, all other Jailed processes would remain secure. FreeBSD Jails securely limits, in an administratively simple way, the amount of damage an attacker can do to a server.

And thought of this thread....

[Primüs]

Originally Posted by DaveQB

Ran into this article: http://www.packtpub.com/article/secu...-freebsd-jails

With this intro:



And thought of this thread....

Pretty much how they should be used. They are definitely not a virtualisation replacement. As I believe I said earlier in the thread, we use jails mainly in a web application environment, where we have a single server hosting the same software but 50 odd instances. We chuck each instance in it's own jail, own IP, own apache/mysql config etc etc, and they run great. Booting up a virtual for each of those instances would be ridiculously wasted amount of resources.

[DaveQB]

Originally Posted by Primüs

Pretty much how they should be used. They are definitely not a virtualisation replacement. As I believe I said earlier in the thread, we use jails mainly in a web application environment, where we have a single server hosting the same software but 50 odd instances. We chuck each instance in it's own jail, own IP, own apache/mysql config etc etc, and they run great. Booting up a virtual for each of those instances would be ridiculously wasted amount of resources.

Cool.
I really think I will be getting into FreeBSD and jails so I have solid ZFS implementation and an OpenVZ equivalent.