GeneralThis forum is for non-technical general discussion which can include both Linux and non-Linux topics. Have fun!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
It's easiest to understand what the "cloud" is by drawing a picture.
Normally, when you draw a diagram of your network infrastructure, you have a lot of boxes for each office and lines in between them. Maybe you have some boxes and nested boxes. But "the cloud" is a cloud shaped container with a bunch of stuff just sort of in there, and lines connecting "the cloud" with other parts of your infrastructure.
The point is, theoretically you don't know the details of where the cloud stuff physically is or how it's all connected. Someone else manages it, and they handle things in a way that when they reroute stuff in case of failures you never see it.
In practice, there's still some real life locations and some real life pipes involved. And in reality, there could easily by a single point of failure. Or, a hurricane hits and one pipe is lost, and suddenly you're sharing on puny backup pipe with ... umm ... EVERYONE else.
So anyway. The theory that you don't need to know the details within that "cloud" shaped container never truly panned out. But whatever.
The point is, this was the idea behind "the cloud". Everything since then that calls itself a "cloud" is just talking about serving up similar services to Microsoft's cloud services. Bearing in mind that Microsoft got blindsided by Amazon Web Services and others and they had to model their revamped Azure services on them to play catch up.
So again, even though it's a private cloud, my servers, are appearently "in the cloud". Now what about my file servers? FTP and SMB? Are they "in the cloud", in a private way, or are they just simply servers?
You can call any private server(s) you want "private cloud" if you want. Whether or not that makes sense to anyone else depends upon how many cloud-like services you provide. Are there cloud style SLAs between the server team and the (human being) clients? Is the infrastructure designed to allow transparent migration and scaling of servers with no impact to the services they provide?
Depending on how many cloud-like services are provided and/or how well they are provided, your "private cloud" may just be a really crummy "cloud", from an outsider's perspective. But who cares what an outsider thinks?
No to the SLA (I looked it up. It is Service Level Agreement). It is a fairly big, small network. There is an AUP, but no SLA. But it is documented when the servers are supposed to run.
I guess it's not transparent either for migration and stuff. Depending on what I changed, the whole thing might change. But I would try to change it gracefully, slowly phasing in and out things. Perhaps things like DNS names are fairly transparent and would probably stay the same.
For example. I've considered that in some new version, it's a canidate to collapse the vweb and vmail servers onto one virtual server. I could keep the DNS names the same if I wanted, but have everything on one server from then on. I could even keep the ports open in the same way, if I wanted, and simply redirect them to the proper IP. Whether I would do these things or not, would depend upon code/users that use it the way it is, at the time of the switch. I could do it gracefully if I wanted to do this. However, it was a pain enough just getting it to work. So for version "a" of the network, it will stay this way.
It could indeed be some kind of "crummy cloud". But who cares what outsiders think, alright. It was tough enough just getting this to work. And if it does it's job for now, who cares how it works? I mean, I love exploring technical details and creating them, but in the end, I just want to do work with it. I really enjoy building troubleshooting skills when things go wrong too (as long as not too many things go wrong). But in the end, I have a job for the network to do. I just want it to do that job and allow me to do the work I need done once it's built.
I haven't really advertised the services I provide to anyone yet. A few outside uses besides me here and there. My sister is using the main FTP server when she needs to install new software onto her Linux System. Which she doesn't really do, or know how to do without my help at this time. We might use an application server to play a game together.
Some "community helpers" are using e-mail regularly, as well as file server space. But really, the majority of the uses right now, is just me. I'm constantly logging onto my existing application servers. I'm always using my website(s) services. My NAS gets used the most often, I admit, such as for backups and accessing software.
But other than that, so far, it's just me and my programs using it. My programs are also constantly using it. Such as DNS queries and stuff. But it's just me and my programs thus far. Yes people send me e-mail, that is routed through my network. But that's about it.
This isn't the end of how I envision it being used, it's just the beginning. See, I want it to be at "version a", before I do a whole lot with it. My focus has been more and more defining and getting things ready for this "version a". Of course, so far, most of my work has been to create servers. These are all marked as "-rec", which means "required". That's because they are part of the standard hardware/software for the network to work. Some are less so than others. If a single App server failed, it would just mean I couldn't access those Apps until it was fixed. But if the DNS server went out, I would have trouble accessing everything until the DNS server was back online. So some services are more important than others, but in the end, they are all "required", in some way or another.
My laptop I'm using right now, is one that is not "required"...
So, I think that for a file server to be considered "a cloud", it means that you need special software of some kind to control it, rather than Internet standards. There doesn't seem to be an Internet standard for clouds yet.
So appearently, I'm going with the fact that you need special software for becoming a "cloud" as far as file servers go. It's appearently another level of abstraction to the servers. One level up from SMB and FTP. It can USE FTP and SMB, but it's not the same thing, really. So, no, I don't have my file servers, "as a cloud".
* My file servers are not "a cloud server". They are simply file servers.
* I definitely have 6/8 servers "in the cloud". They are "in the cloud", because they are virtual machines, and don't exist in the physical world.
* I am only using private clouds right now, except where they can be gotten for free, such as google. In other words, although I can access most of the services provided by my servers from anywhere, I normally access them from right at home. I make use of things like Google Drive, which is a cloud file storage provider. However, I do not make heavy use of it. I will make more use of it in the future. After all, it's free storage. But for now, I don't make use of it. I only use these services right now, when they can be provided for free.
In general, my network relies on "clouds". Although my network may be primarily used by clients, it couldn't be created without the concept of "clouds", and virtualization. I couldn't run 12 physical servers in my apartment. There is not enough power outlets, power, or space for all those servers. Even if you used laptops for them, as I'm considering doing more of in the future. Laptops can be stacked, if they're modern enough. I could have at least 3 of them, in place of 2 desktop machines. But that is probably way, way in the future of things.
I still don't know what "Internet Backbone" means, but that is a topic for another day. Put your input fast if you disagree, because I'm thinking I found my answer...
Help! I think I found my answer now. I was going to "mark as solved". But I can't find the link! It's missing! Anyway, like I said, this gives one last chance to see if you disagree and it's not really solved yet, if you disagree with valid input about my last post. But anyway, either way, where did the link to mark as solved go?
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 7,680
Rep:
Quote:
Originally Posted by des_a
Really? Maybe I got my history wrong when I learned it.
From the accounts I read it would appear the Grace Hopper was making fun of an already existing term when she reported the "bug" in her computer. Wikipedia pretty much sums things up as I understand them.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.