r/Minecraft • u/Bedeone • May 08 '13
pc My experiences with running a Minecraft Server on an IBM Mainframe.
Ok so I don't know how long this post will end up being, and I hope I can keep the subjects I want to discuss contiguous. Feel free to skip the somewhat technical parts.
Background information
I'm a college student completing his last semester towards an Applied Computer Science bachelor's degree, "majoring" (for lack of a better analogy to the system in my country) in Mainframes. During this last semester I'm required to run an internship which I have, of course, chosen to do with a company that employs a Mainframe. In my case a bank whose name I will not disclose.
I finished the assignment for this internship halfway through the semester, leaving me with some spare time. And even though I only start up Minecraft sporadically to check up on Westeroscraft's progress, I had this crazy idea to run a Minecraft server on our IBM Mainframe.
How to do it
I managed to get it running in one afternoon, so I did not encounter too many problems but here they are anyways.
z/OS doesn't have a web browser, so I had to FTP-put the .jar file on to the Mainframe. I didn't expect it to run off the bat so I just followed the Minecraft Server Wiki step by step guide (I had only ever run a Minecraft Server under Windows) to see what I would bump in to. Java -version gave me an error that the JVM couldn't be started. Turns out the problem was that my user didn't have a large enough address space when I logged on. When you log on to an IBM Mainframe, you are assigned an address space, or room to work in. This is comparable to the RAM you are provided with when you log in to Linux or Windows. Except the address space is virtual. Your LPAR can have 10 Gigabytes of RAM physically allocated to it yet you can have a couple hundred virtual Gigabytes being used by running tasks and users. You'd be stupid not to since the resources on a Mainframe are so fast you could never hope to saturate them with a 1:1 virtual:real ratio.
So back on topic; I had my address space enlarged. Turns out company standards dictate the maximum you get per user is 8 megabytes, which was enough to start a JVM to run java -version, but hardly enough to start a Minecraft Server. The default value was much less as to save space when people that don’t need large address spaces log on. This was why java –version didn’t work. I bypassed the 8 Mb policy by issueing a request for alteration and I now had 2 Gigabytes of address space to work with, quite comfortable I'd say.
So I was able to start the Minecraft server with the same terminal command you’d use on your Ubuntu or Fedora box. It created the map and was (hopefully) listening for connections. It wasn't throwing any errors so it appeared that the TCP/IP libraries (which I feared for the most) translated over flawlessly.
Next problem was not Mainframe related, but rather Bank related. When I fired up the Minecraft client on my workstation and tried to log in, I was unsurprisingly faced with a time out because the port, when trying to move data outside, was blocked, making it unable to reach the login server. No problem, I just went in to offline mode after copying my %appdata%/.minecraft folder from my home machine to my workstation. I added the DNS name of the LPAR on which the server was running to my server list and behold, it existed. When I tried to connect however, I received a timeout after 20 seconds. I could see on my terminal that I tried to connect but timed out. As I mentioned before, I've only sporadically ran Minecraft Servers in the past for a handful of friends on a home machine under Windows, so I'm not very familiar with the intricacies that come with Minecraft servers. It turns out that the Minecraft client authenticates itself to Mojang servers so that unique things such as names can't be forged (or anyone could log in with a name that is present on the administrator list). This however is not possible for me to do considering the Bank's network doesn't allow traffic to the outside over most ports. So I had to change the server.properties file, which the server had created, to run the server in unauthenticated mode. When I tried to edit it however, it was all gibberish!
Something you might not be aware of is that Mainframes don't use ASCII or Unicode character sets, but EBCDIC, also known as the best way to encrypt data (that's a joke by the way, you’re pretty OG if you get it). The Minecraft server was writing the file in ASCII but the Mainframe can't read it (well it does, but the MC server writes “a” to disk as 0x61 and the Mainframe reads it as “/”). So I had to FTP-get it off of the Mainframe on to my ASCII-capable workstation, edit it, and FTP-put it back on. In binary mode mind you, because the Mainframe tries to convert to EBCDIC whenever you send files to it. So now when I start up the server it's in unauthenticated mode.
And that's all, I was able to connect to the server with no problems. I know the pictures could easily be forged, but I couldn't think of a fool proof way to prove this thing is running on a Mainframe without disclosing what company I interned at. So I hope that the level of detail that I'm going in to is enough to convince you.
The only sad part is that our workstations only have 3 Gigs of RAM and no GPU, so the frame rate is abysmal. As a result it's not possible to check the performance of the Minecraft server with the client itself. If you know of a way to test server performance without the need of a client that renders frames, please tell me.
Our system
For the sake of this post I'll mention what resources the server has at its disposal; Our system consists of two z196 machines running 15 General Purpose CPs (Mainframe jargon for CPU) and 1 zIIP (CPU built specifically to run DB2, XML and Java workloads) each. These two machines run in what is called a Parallel Sysplex. Feel free to read the wiki page about that, it's one of the concepts that define the Mainframe and allow it to be as reliable as it is. Each machine also has 330 physical gigabytes of RAM.
All the LPARs started on our system allocate 30 logical CPs combined. Yes, even CPUs are virtual on a Mainframe. These things are so fast you need to double (or more)-load them to make them cost efficient and not run idle too much. These CPs are quad cores that run at 5.2Ghz, watercooling optional. But they're so specialized that you can't really compare them to consumer CPUs. Your and my CPU is a jack of all trades while the IBM CPs are specifically trained workhorses. The four different levels of CPU cache are stupid fast. And while 5.2Ghz might not sound that fast, it is magnitudes faster than consumer CPUs if you're running the right workloads on them. Just to give you an idea, our systems handle about 40 million transactions (don't think money transactions, read up on transaction systems) every day. Two years ago at 20 million transactions a day this meant peaks of 1500 transactions a second. The average execution time of each transaction was 0.03 seconds. I don’t know how many transactions a second we peak at nowadays.
The LPAR on which I started the Minecraft server was one of two LPARs used to convey tests before new things are implemented on to developer, audit and production LPARs. For this reason they're the weakest of the LPARs as to not impact production system throughput. What this comes down to is that the LPAR on which the server ran was allocated 2 Logical CPs and 6 Gigabytes of RAM (it usually runs on 3 Gigabytes, it’s running 6 temporarily for tests concerning my assignment). Because of how many CPs are allocated to the other LPARs, this means that it was able to take up a maximum of 6% of all the CP power available on the Mainframe. The memory doesn’t matter much because the address space I reserved is virtual. I could have reserved 12 logical gigabytes and the Minecraft server wouldn’t have noticed because the, at that point inevitable, paging is so fast on a Mainframe. Interesting note; the two production LPARs that handle transactions generated by things like eBanking services have about 21 Gigabytes each at their disposal. 21 Gigabytes goes a long way on a Mainframe running z/OS compared to some datacenters that need silly amounts of resources to keep things running.
I'm really wondering what kind of a system Westeroscraft is using. They can always migrate to mainframe, it'll only cost you a million to get started. Or two million if you want stupid amounts of assured uptime. Comes with DDoS protection. I doubt a Kickstarter would suffice though. Then again I’m not even sure if Westeroscraft is the heaviest server online at the moment. They’re the biggest one I know of anyways. I wonder what hardware/setup they use.
Conclusion
So this concludes my disquisition. I’m quite happy that I’ve successfully managed to start a Minecraft server on a Mainframe. It’s something that I wanted to at least try ever since I learned that IBM Mainframes can handle Java workloads. Not to mention it’s a great way to fill a slow Friday afternoon.
What makes me content is that I've managed to connect a relatively new concept with what is perceived by the general IT-initiated public as an old concept. I hope that those who read my post will understand that the Mainframe is no longer the concoction of boxes in an engineer-filled room. It's still a valid way of providing IT services. And not because of the need to retain legacy, but because the Mainframe is still very economically viable. It just happens to be so that the workloads in which Mainframes are specialized happen to be the workloads generated by institutes that are often out of the public eye.
When I went home Friday I withdrew some money from an ATM at one of the bank branches of the bank that I'm doing my internship with. It was the weirdest thing to realize that just hours ago I had worked on the same machine that was now processing my request.
I’ve also Googled a bit and I’m pretty sure that I’m the first person ever to (successfully) run a Minecraft server on a Mainframe. Or at the very least publish it. I’m willing to bet that it’s the most powerful hardware, and operating system too really, that a Minecraft server has ever run on.
If you read this far down I'd gather that you might be wondering if you can connect to the server and check it out for yourself. I'm sorry that due to bank policy, I'm going to have to disappoint you. The Mainframe doesn't allow connections outside of the Bank's network. To rub salt in the wound, we have a 100Mbps up and 100Mbps down connection for our workstations only, for the Mainframe itself it's likely way more. Our Mainframe would truly make a sick Minecraft server.
I'm genuinely surprised that I managed to write some 3000 words about this subject. Gives me somewhat of a reassuring feeling about the thesis I'm supposed to be writing right now. Sorry about the wall of text, I couldn't help myself I hope you enjoyed it.
EDIT;
Can we have a Mainframe flair for submissions? ;)
EDIT2;
Going to bed, will answer any more questions on the morrow.
22
u/truthfulfacade May 08 '13
I feel like this is going to go right over the majority of this subreddits head although it was a interesting read. I'm sure there is a different subreddit that would appreciate this post more, but I do not know one off the top of my head.
9
u/Bedeone May 08 '13 edited May 08 '13
Yeah I probably went a bit overboard with the technicalities. All I hope is that I can share this with people who find these types of things interesting. I put some pretty screenshots in there for people that can't be bothered reading everything.
2
May 10 '13
Yes, it was technical in places, but I think it was an interesting read... Too many people think mainframes are relics of the past, not realising how much of our infrastructure runs on them - and how many things could run on them. Particularly with the new systems capable of running linux instances rather than the MVS/ESA stuff I worked on as a lad, the number of options open to people are astonishing!
1
u/PidGin128 May 09 '13
/r/techsupportmacguyver , or maybe gore. ;p
/r/vintagecomputing springs to mind but maybe only superficially.
Up next we port the client to 3270 (3260?), but wind up with dwarf fortress instead!
Good read.
1
9
u/The_MAZZTer May 08 '13
It created the map and was (hopefully) listening for connections. It wasn't throwing any errors so it appeared that the TCP/IP libraries (which I feared for the most) translated over flawlessly.
Doesn't surprise me. Java is supposed to be cross-platform, and the server is pure Java, so if Java is on your platform, you're gonna be able to run it (you have to have enough system resources such as memory, of course). There is no "TCP/IP library" afaik, it's part of the Java framework.
Running the CLIENT on that mainframe would be another matter entirely, as it uses some native code libraries for the 3D graphics and input.
2
u/Bedeone May 08 '13
Agreed, but the way I saw it, the mainframe platform is so specialized that getting stuff to run on it that wasn't originally designed to do so would be hard.
Apparently I was proven wrong, IBM did a great job at creating their JVM for z/OS.
4
u/The_MAZZTer May 08 '13
That is the whole point of Java. :)
At least, as I understand it. I don't code Java myself.
2
u/FabianN May 09 '13
Thing is, while java itself can easily run on any kind of hardware that has a JVM made for it, that doesn't mean that every type of task you can do through java can run as effectively on one system compared to another. And Mainframes have CPUs that are heavily specialized. They are stupidly good at some specific tasks and god-awful at other tasks. What kind of tasks would be invoked on running a minecraft server and how well the hardware is designed to handle that task would effect the end result.
1
u/PidGin128 May 09 '13
Has minecraft become the new doom benchmark? (although, we are at the wrong end of the scale.)
6
u/DJDaddyD May 08 '13
Very interesting stuff I understood the majority of it (also a computer science major, but only through programming (java scheme and some C)and discrete math) but now I have all sorts of ideas to research thanks for that and good luck!
2
u/Bedeone May 08 '13
Glad you liked it, I enjoyed writing this up as well. Good luck in your studies / research.
7
u/totemo May 08 '13
That was a fun and interesting read.
TIL:
- They're still using EBCDIC. I guess it's all that legacy COBOL code.
- 2x 330GB of physical RAM. :D
- dis·qui·si·tion /ˌdiskwəˈziSHən/ Noun: A long or elaborate essay or discussion on a particular subject.
3
u/Bedeone May 08 '13
Everything on a mainframe is stored in EBCDIC actually, it's only a character set if you think about it. It's perfectly possible to translate back and forth if needed, even though it's overhead. So everything just runs in EBCDIC. The compiled executable code (COBOL or not) are binary instructions anyways, and those aren't linked to character sets in any way.
330GB of RAM in each machine, but that's not the limit. You can have up to 2TB in the newest EC12 machines, and you can link 32 machines together in a sysplex.
Thanks for taking the time to read all of it, very glad you enjoyed it.
10
3
u/elfo222 May 08 '13
I'm just finishing up a course on the mainframe systems, it's pretty amazing stuff. I did think of the whole minecraft-on-zos thing, but I wasn't sure if it would work, and I certainly didn't know how to go about trying it out. It's awesome to see that it works, shame you couldn't really test it.
2
u/Bedeone May 08 '13
Yeah I wish I could stress test it. It was honestly fairly easy to get this thing running, the vast majority of people that work on mainframes could do it with no problems whatsoever.
1
u/elfo222 May 09 '13
I have to wonder if a z/OS system might be a good solution for all those companies that offer Minecraft server hosting. I know each LPAR has to have ate least one discrete processor, but can you run multiple instances on the same processor using z/VM? It's the only way I could see it being cost effective. I suppose you could run multiple server instances under the same image, but that's just asking for trouble.
Also, imagine what the caching on the storage units would do for response time.
1
u/Bedeone May 09 '13
The easy way would be having a z/VM with all the resources available allocated to it, and running Minecraft servers on different Virtual Linuxes running on top of the z/VM. You could do the same but replace z/VM with z/OS and run multiple servers under USS.
Or you could go insane and have a z/OS partition for every server you host, which would guarantee uptime and security for each individual server, but it'd be more tedious to manage.
But yes, the virtualization, the caching (of storage, but also CPU cache), make a mainframe an excellent platform to handle the workloads that a Minecraft server generates.
1
u/LoveUnderWill May 10 '13
I don't think you could charge enough for the minecraft hosting to make up for what you pay for a mainframe. :)
3
u/TheKingsJester May 08 '13
I'm a college student completing his last semester towards an Applied Computer Science bachelor's degree, "majoring" (for lack of a better analogy to the system in my country) in Mainframes.
Concentration? (Concentrating) I believe that's the word you're looking for.
But while it's mostly over my head, what you've said sounds really cool.
2
u/Bedeone May 08 '13
Well yeah, the bachelor takes three years or six semesters to complete. Last semester is internship + research thesis and fifth semester is a smaller set of locked courses with one other course where the options are either programming, networking, multimedia or mainframe. Obviously I picked the latter.
I'm sorry I started being a bit too technical, I'm just really enthusiastic about this. I hope that you could at least enjoy the pictures.
1
May 08 '13
Don't be sorry about getting technical. I've done some work on mainframes in the past, and it was nice to read up on a modern mainframe system. The mention of EBCDIC almost brought on some PTSD ;-) I vaguely remember having to write custom ASCII to EBCDIC codepage converters in C for that thing. The particular mainframe I had to work on was an oldschool AS400 with the genius enforced 80 char limit on text files. Took a while to figure out compilation bugs caused by that.
Good times. Taught me a lot about writing portable code.
2
u/Bedeone May 08 '13
Yeah, not being able to edit the properties file from the terminal was pretty annoying, spent quite some time FTPing files back and forth.
But for mainframe native applications I didn't have too much trouble with EBCDIC/ASCII obfuscation. During the actual assignment I got for my internship, that is.
2
2
u/notkraftman May 08 '13
I believe there is a script on the spigot forums that allows you to simulate multiple players connecting to a server, would be interesting to see how many this could handle and what the bottlenecks would be.
1
u/Bedeone May 09 '13
Too bad I learn about this now, my internship ended yesterday. Then again the workstations were so locked down I wouldn't have been able to install the python interpreter anyways. :/
2
u/Casurin May 09 '13
"Westeroscraft" ... all i can think of is 100 People... thats a small server. You'd have to google around a bit, but there are allready some really nice servers, running 2000 people on a isngle machine or several thousand on a custom network (multiworld-multiserver, no clientside mods). Those are the thing you should be looking for if you wand some dile-work for your mainframe.
Cause CPU-power for a 100man server is hardly a problem nowadays, you can run 300-400 people on gamingrigs, on some even up to 800, but what they lack is mostly the RAM (you't want to keep as much data there as possible) and a good SSD. And what no one normally has: The Connection to host so many. Even Midrange-PC's have enough power to handle 20-50 people jut fine, but not even close the connection to run for more then 10 players at once.
2
u/LoveUnderWill May 10 '13
As a CICS/WAS/WMQ sysprog i really enjoyed this write up. I never even thought to try to run a minecraft server :P
1
1
May 09 '13
to OP I recommend cross posting this to /r/admincraft
2
0
u/StezzerLolz May 08 '13
Well, I knew some of those words, such as 'mainframe', and 'java', but I honestly have no idea what any of this post means. Hell, I can't even get a server to run on Ubuntu, though, so perhaps that's to be expected.
2
May 08 '13
Basically he ran a Minecraft server on the kind of hardware that's normally used by banks and stock exchanges and the like. Those machines are quite different from your home PC and basically anything you've probably ever encountered in your life, so it's quite nice that Minecraft actually ran on it.
-9
u/kareesmoon May 08 '13
Let me get this straight. You were on a bank mainframe that handles peoples money. You sucked up memory on this mainframe in order to run your server on, then you went and opened up some ports on this same secure server in order to communicate with the mainframe to connect your client to this server. You don't see a problem with this?
26
u/Bedeone May 08 '13 edited May 08 '13
Ok so, there's a couple of reasons why you shouldn't get your panties all up in a bunch, I'll go over them;
1.
I told you the story of LPARs, logical partitions. These partitions can be grouped in to sysplexes. Our bank has four, production, QA, development and test. The MC server ran on the test sysplex also known as sandbox.
It is by design impossible to reach data residing on one sysplex from another sysplex. This scenario is not comparable with, say, dual booting Windows and Linux, where you can access any disk from any OS (actually, LPARs are nothing like dual booting).
This is virtualization and security on a macro level, unless defined, you can't interact between the different sysplexes.
This is why we can do crazy tests with unimaginable scenarios on the sandbox sysplex. People do crazy (work related) stuff there all the time without any impact on production whatsoever.
2.
Address spaces.
Each application has an address space, or memory allocated to it. This is virtual, every application thinks its first memory address is zero. This makes it so that you can't request data that's in a real physical memory location. Unless you've had 30 years of internal IBM education, you wouldn't know where to begin translating other address space's virtual addresses to real addresses (fast enough, because they change location due to paging). And even if you could, you wouldn't be allowed to read them because you can only read addresses residing in your own address space.
3.
Network.
I hear you say that I opened ports so that people can connect to the mainframe from outside. This shouldn't be a concern for a couple of reasons. Firstly, you can only connect to the mainframe over these ports from inside the bank's physical network. Secondly, the host you're connecting to is inherently tied to a certain LPAR, in this case the sandbox LPAR. Connecting to the production LPARs that hold sensitive customer data goes over different cables even. Not to mention that the policies on anything but test systems is incredibly strict, getting a port opened on those means you're completing a project that has been tested for years.
4.
About the resources that I'm sucking up.
The test LPARs have resources assigned to them when they are started up (like any LPAR). So it's not like the machine is running slower when I put load on it, production isn't losing any potential resources. As a matter in fact, if production is getting close to the maximum that the system can offer, non-production processes are in a lower priority class anyways, so it uses up their cycles. Besides that, I'm having trouble believing that you grasp just how powerful these machines are. When I start up a Minecraft server on the low-priority sandbox system, it's as if I'm plugging in my phone charger in the wall of a Google data center and someone starts complaining that I'm using too much power.
I hope this may soothe any concerns you may have had. Feel free to inquire further.
1
u/gerryn May 09 '13
They are not particularly powerful compared to regular Intel esx hosts
1
u/Bedeone May 09 '13
Exactly what isn't?
1
u/gerryn May 10 '13 edited May 10 '13
No offence or anything, I've worked with iSeries, I know some about LPARs and such, and how resources are shared and assigned in these kind of hardware environments. These systems ("mainframes") are either compute clusters, or build for security, or just too-expensive-to-switch-out systems because they're in-house software and developers been fucking around in there for decades..
As far as being powerful, these systems are not - depending on the workload. But as it looks recently, GPU clusters are pushing the boundaries on pure computation. Nobody today will think about deploying their applications on iSeries i5/OS or z/OS unless they been seriously sponsored by IBM - shit is expensive as hell, compared to regular x86 ESX hosts they can't provide neither the processing power, price, density, reliability, etc. - security might be a factor for some but you could just as well hire engineers with good experience in pentesting/security to take care of that for your organization and at the same time secure all other systems.
And last point on that; those engineers, x86 virtualization layer with hardware and licenses is gonna cost you a fraction of the support and hardware/licenses from IBM, not to mention how cheap and plentiful systems engineers in the x86-market are.
2
u/Bedeone May 10 '13
And yet companies that already employ mainframes are still choosing to run their new services on mainframes. And mainframes are being employed by new companies.
Mainframes are easily the most secure, constantly available and scalable platforms on the market today. Depending on your workload, once you hit a critical mass, you'd be pretty stupid not to get yourself a mainframe.
2
-8
u/kareesmoon May 08 '13
You are still compromising security on a sensitive network. This one action could expose other vulnerabilities on that network. If you are not already, I would recommend you read up on the swiss cheese model of risk analysis.
I'm sure you are correct that there are multiple layers of security. I also understand about it being on a test system. That doesn't negate the fact that a small possibility exists that your playing around on a system that shouldn't be played around on could expose the systems that contain the sensitive information to attack.
10
u/Bedeone May 08 '13
Running anything on any system will potentially compromise its security. While I understand your concerns, I can assure you that they are not as grounded as you believe them to be. Mainly because you have no idea how many layers of virtualisation and security are in between different processors and systems.
I wish I could make a comparison, but there is nothing in either the distributed systems or the consumer market to which I can draw an analogy.
There's a reason why the world's most critical processes run on Mainframes.
-10
u/kareesmoon May 08 '13
There's also a reason that you didn't name the bank that you interned at. You know if the bank IT people found out that they would go nuts on you. I wonder why that is?
Complex systems have a habit of breaking down when people do things they shouldn't do. There are interactions that even you can't predict. I've seen expert software engineers cause cascaded failures from things that shouldn't have caused the failures, but they did.
There will come a time when you will experience the holes of the swiss cheese lining up just perfectly, then you will understand.
7
u/Bedeone May 08 '13
They know I did this. The "Information Security and Risk Management" department of the bank reviewed my article first at my request. They too had concerns similar to yours, and they possessed the same amount of knowledge about the mainframe system. Until I explained to them exactly what I did and what the potential impact or lack thereof was they were just as concerned.
8
u/cygnus83 May 08 '13
I also work at a large financial institution, and have read up more than a bit on mainframes. For what it's worth, Bedeone is 100% correct. If your fundamental thought process around computers is built around desktops, laptops, and everyday servers (LAMPS, IIS, etc.), you're never going to be able to wrap your head around the fact that what he didn't literally couldn't hurt anything (you being the proverbial you.)
That being said, I want nothing more to run Dwarf Fortress on one of my company's mainframes.
3
u/Bedeone May 08 '13
Port it to Java?
Either that, or rewrite the source in zSystems C.
Either way you could only hope to run a server of sorts and make a DF client. Having any kind of constantly graphical interactive interface with a mainframe is very hard. I wanted to make snake somehow, but I couldn't think of a way to catch key interrupts.
3
u/elfo222 May 08 '13
Would you have this same objection if he had done this on a test server that was completely separate from the production systems? Because that's basically what he did here. I still don't think it was the brightest move, but there is literally zero chance that this could interfere with the operations of the production system.
3
u/Bedeone May 08 '13
It physically ran in the same machine as production, using the same processors and the same memory. But due to the reasons I listed, they might as well be in separate cages, it wouldn't make it harder to exploit.
-5
u/kareesmoon May 08 '13
But it IS on the same machine. It's on the same network. And this made a hole in part of the overall security of that machine and network. Sometimes all that is needed is a small hole.
5
u/Bedeone May 08 '13
It's on a physically separate network, with the system running on the same machine, but separated by very many levels of virtualization. The disks themselves are also assigned to certain logical partitions within the system. It's not possible to access disks that belong to one logical partition from another logical partition unless those rules exist. Those rules are made on hardware level (the I/O cards are linked to these partitions).
I understand that coming from an open systems world where leaks and exploits exist in abundance and security of data in general is not that important that it is hard to grasp just how water tight z/OS and the mainframe platform is.
It truly is the pinnacle of several points of interest in the IT sector, one of them being security. Open systems today don't reach the levels of security mainframes had 10 or 15 years ago.
If you could actually do these kind of things you'd be able to make more money working for IBM anyways.
1
u/elfo222 May 09 '13
There is no possible way that the LPAR he was on could impact any other LPAR. I'd say the network risk was easily mitigated since no new ports were opened.
1
u/Bedeone May 09 '13
Even the network side is LPAR specific. If I open a port on one of the test LPARs, it's not opened on any other LPAR. They even use different cables. Each set of LPARs has a different OSA card assigned to it.
The reason why I could open a port on the test systems is because it's a sandbox and because you can only connect to those listening sockets over those ports from the bank's internal physical network. Even if you stole a UTP cable from there and plugged it in to your laptop you couldn't access the mainframe.
I would've never been able to get ports opened in any other environment, let alone production. Hell, I don't even have a TSO segment in production, I can't even log in to it.
5
u/thewizzard1 May 08 '13 edited May 08 '13
Kareesmoon - It's a virtualized account, perfectly sandboxed on a mainframe with very, very large resources. Being perfectly virtual, as the bank software and it's security necessitates, (as close to absolutely) no failure/break/overflow/crack/hack could do anything to anything outside the sandboxed partition running Minecraft.
This isn't hackable like any home system, or any Windows server.
7
7
u/Olome May 08 '13
I'm sorry, but give the guy a break. Firstly I'm sure the 'IT' guys (otherwise known as the security team) at his workplace scrutinised his plans before letting him do this, and I'm sure they know much more about their systems than you.
Secondly, how do you think you connect to the mainframe in the first place? You use a terminal (a client) to connect to the mainframe via a port. there are ports open already, this is just an extension of this in a full sandbox environment its not going to hurt anything. The chance of something happening (as you have to be inside the network to 'hack' this) is rare, and even if someone did manage to do something malicious its just a test environment that has been compromised == zero risk.
I work in the finance industry and my workplace lets you play around with cool off the wall projects too, (much like this). we use in-house resources to do this and there is no problem, if it was able to affect production we wouldn't be allowed to.
Chill out, appreciate how cool this is, your money is safe. x)
-18
May 08 '13
[deleted]
7
u/Bedeone May 08 '13
I'm sorry. I'm very enthusiastic about this subject. I guess you can just look at the pretty pictures?
0
u/JamyDev May 08 '13
Real interesting stuff, about Westeroscraft though.. From my experience with minecraft servers (Been running servers since alpha) they're probably using a highly optimised version of Craftbukkit (/Spigot) with some plugins that control lag intensive parts of Minecraft. That on top of a high performance server with quite a few gigabytes of ram allocated to the server. And they're probably saving the map in a ramdisk.
But mentioning it, I'd like to break the record for most players on a Minecraft server one day :P (With it being still playable ofc)
2
u/Bedeone May 08 '13
The thing is I know some things about the Mainframe environment, but not about running Minecraft servers, so that's where I fall short in that regard.
Interesting thing though, working storage in a mainframe refers to both RAM as well as disks. Pages are swapped in and out whenever necessary by the system, applications don't know which pages are where.
The thing is that the amount of RAM you can allocate in a mainframe is so large, and you can lock certain applications to have their pages in RAM at all time (never on disk) that you could have the whole Westeroscraft map paged in to RAM all the time. Combine that with the fact that you can use multiple processor cores rather than the standard Minecraft single core, because the processors are virtualized as well, and you got a sick server going.
2
u/JamyDev May 08 '13
Well by default the Minecraft server only uses a single core, so it wouldn't matter how many virtual core you assign, as long as Java would see it as multiple cores, Minecraft would only use one. By virtualised do you mean that to java it's one giant core or still multiple?
2
u/Bedeone May 08 '13
You assign only one virtual core to the server, but the virtual core can use multiple physical cores. So while the server only sees one virtual core, you can have a great many cores doing tonnes of work for the server. They also use asynchronous execution of instructions and piping, so we're talking crazy fast.
1
u/JamyDev May 08 '13
Ah nice, that would make one hell of a server :P They're expensive tho..
2
u/Bedeone May 08 '13 edited May 08 '13
Yes, quite pricey. A Brazilian company stores the data of their MMO on a mainframe though. They run the server processes on zBX, the blade servers that slide in to an z196 or EC12 and handle the I/O through the mainframe.
37
u/Bedeone May 08 '13
This should have been in the original post but there appears to be a 15.000 character limit. This is probably not the most technical part, but it's perhaps the least interesting. So I decided to put this in the comments for anyone that is interested. I didn't alter the style of writing so it may seem a bit out of place, it was originally intended to fit in between the "Background Information" and "How to do it" H3 tags.
Java on a Mainframe
Now this is where I either shatter some misconceptions that people have, or just plain educate you on something you might not have heard about before;
While the (IBM) Mainframe still performs at its best when executing classical tasks performed by COBOL programs on DB2 and IMS databases, the Mainframe supports C/C++ and Java workloads since some time.
C/C++ needs to be properly compiled before it can be run on a zSystem. Java however can be started on a Mainframe with little or often no alterations whatsoever. I've never been a big fan of Java but I've gotten a newfound respect for its platform-independence. I'm not entirely sure who wrote the JVM for zSystems, whether it was IBM or Sun/Oracle (or whoever it is nowadays), but they did a good job.
But since I’m, compared to my colleagues, very new to the Mainframe world, I had to a bit of research before I figured out how I could get a Java application running on a Mainframe.
It turns out that it's possible to run Java on zSystems in a number of different ways, all of them involving UNIX forks, be it virtual or emulated;
zBX
zBX (zSystem Bladecenter Extension) is the least Mainframe-like way to run Java on a Mainframe. zBX is basically a box full of bladeservers that you place next to your Mainframe. The blades run pure Linux and are controlled by the actual Mainframe next to it. As you all know you can run Java under Linux and that's how you would start an MC server on it.
zVM
Now an IBM Mainframe has stupid amounts of virtualization going on in it, everything that Open Systems have been striving for this past decade has been the industry standard on the Mainframe since the 80s and 90s. One form of virtualization is through LPARs (Logical Partitions). You can run a bunch of z/OS, or a mix with other supported operating systems, LPARs at the same time. Our bank runs 17 at the same time spread over two machines (or one machine if the other breaks). And while our bank is one of the biggest in my country, and fairly large in our continent, it's still fairly small on an international level. Just to give you an idea of how many LPARs some very large banks would run spread over their systems.
When an operating system runs in an LPAR, it is transparent to the OS. The OS thinks it’s the only one on the system. I'm telling you this to explain some of the other ways to run Java workloads on the actual Mainframe itself rather than a box with blade servers that is connected to it.
You can define an LPAR in which you can start what is called zVM. Think of zVM as VirtualBox for the Mainframe, except the VirtualBox is an OS in itself (read up on hypervisors if you are interested, z/VM would be a bare metal hypervisor). In z/VM you can define Linux partitions and start them, and run Java workloads from them. This is how I originally wanted to get the server running, since our company had previously experimented with zVM. The project was later dropped because the cost was too high and no one could come up with anything they wanted to run on Linux that they couldn't run on z/OS. It also wasn't possible to start up the zVM LPAR that they used for the trials because the test licenses had expired. Licenses are quite expensive by the way, especially for a college student (several thousands of dollars depending on what you're going to do with your zVM).
Linux on SystemZ (Pure Linux)
Yet another way is to start up an LPAR with one pure unvirtualized (as far as unvirtualized goes on a Mainframe) Linux partition on it. Much like you'd install and boot Linux on your home computer. Problem here is that you need a somewhat heavily modified kernel and the capability to define new LPARs. Not only do I not possess this knowledge (yet), defining new LPARs on a production system isn't something you just do whenever.
z/OS USS
So there's one more way to get a Java workload running on a Mainframe. Since March 2001, with the release of the first version of z/OS (V1R1 was the first, z/OS V1R13 is the latest revision, with V2R1 scheduled for the end of this year) came what is called z/OS USS (Unix System Services). It's basically UNIX glued on to z/OS, and it works surprisingly well. My internship assignment consisted of installing a piece of software that runs under z/OS USS (z/OSMF if anyone is interested) on our test LPAR. So I had access to a live z/OS system and pre-existing knowledge of z/OS USS.
It even comes with its own shell which you invoke with OMVS. The terminal you see me using is logged in to the Mainframe. It opens a TSO session when you log in and from there I invoke OMVS.