This is my first time working with a team that manages networking and other things. At work I was able to plan out the networking with a few others and if we ever needed something done it was usually something we could handle ourselves. You don't really have the kind of freedom and ease for doing those kind of things when you have to send in requests for a lot of different tasks.
I'm not really complaining, it's just a different experience. The most important takeaway is to plan out what you need in advance and send out requests as soon as possible. Some things will take more time than others as some tasks need to be verified to ensure network security and they definitely have other tasks to deal with than ours.
One big holdup we had was the networking for the cluster. It took Dillon and I a bit to figure out exactly what kind of networking we could do as well as what we wanted to do. The original cluster had one IP on WSU's LAN, and then a machine acted as a router and handled a separate LAN just for the cluster. We figured that wasn't really necessary and it would be easier enough to just have each machine with an IP on WSU's LAN instead. Initially we decided to just use the next 10 IP addresses from the block we were given for virtual servers. This set-up didn't work at all, and we figured those IP addresses were on a separate VLAN or something like that. Dillon later attempted to use the IP that was assigned to the server before but that didn't work. We could acquire IP addresses from DHCP, but we wanted some static IP addresses that we wouldn't have to worry about IP conflicts due to being in the DHCP pool or anything like that. We then had to ask UTS about getting some IP addresses, and while we waited we would just install the servers using the DHCP addresses. When UTS got back to us they told us that the whole block of the IP address that was given for the cluster before should be available, but we had already tested it and it didn't work, but we tested it again just in case and still it still didn't work. So we had to troubleshoot with them, and eventually we found out that the VLAN assigned to that port was wrong and got everything sorted out. It was kind of a hassle overall, but we definitely could have avoided it if we tested IPs and figured them out earlier in the semester.
One thing I was working on individually was Google Apps authentication for the wiki. I'll go into it more in a post about the wiki, but after setting it up I found that the feature wasn't enabled for WSU accounts. So we had to see if UTS thought that was a good feature to enable- I'll give an update once we get that up or not.
We had the IP addresses available to us for the virtual machines in advance, Dr. Wurst had asked about them earlier in the year for the server for the CS401 project so we were all set regarding those.
In one particular case we avoided UTS altogether. When we were moving the new CS server to production, we found that the old server wasn't assigned the public IP address directly- it was assigned a local IP address. This sounded like a 1:1 NAT set-up, which is essentially where you have local IP addresses for devices on your network and you route public IP addresses to certain IP addresses. So for moving the new CS server to production, we figured just changing the IP address from the old one over and giving the new server the old one's local IP address we'd be able to put it in production with no issues. We were able to do this and everything worked out well.
Overall I'd say working with UTS was a good thing. It definitely caused a bit of hassle as it wasn't really what I was used to, but overall a team like that is definitely a good thing to have.
This is my first time working with a team that manages networking and other things. At work I was able to plan out the networking with a few others and if we ever needed something done it was usually something we could handle ourselves. You don't really have the kind of freedom and ease for doing those kind of things when you have to send in requests for a lot of different tasks.I'm not really complaining, it's just a different experience. The most important takeaway is to plan out what you need in advance and send out requests as soon as possible. Some things will take more time than others as some tasks need to be verified to ensure network security and they definitely have other tasks to deal with than ours.
One big holdup we had was the networking for the cluster. It took Dillon and I a bit to figure out exactly what kind of networking we could do as well as what we wanted to do. The original cluster had one IP on WSU's LAN, and then a machine acted as a router and handled a separate LAN just for the cluster. We figured that wasn't really necessary and it would be easier enough to just have each machine with an IP on WSU's LAN instead. Initially we decided to just use the next 10 IP addresses from the block we were given for virtual servers. This set-up didn't work at all, and we figured those IP addresses were on a separate VLAN or something like that. Dillon later attempted to use the IP that was assigned to the server before but that didn't work. We could acquire IP addresses from DHCP, but we wanted some static IP addresses that we wouldn't have to worry about IP conflicts due to being in the DHCP pool or anything like that. We then had to ask UTS about getting some IP addresses, and while we waited we would just install the servers using the DHCP addresses. When UTS got back to us they told us that the whole block of the IP address that was given for the cluster before should be available, but we had already tested it and it didn't work, but we tested it again just in case and still it still didn't work. So we had to troubleshoot with them, and eventually we found out that the VLAN assigned to that port was wrong and got everything sorted out. It was kind of a hassle overall, but we definitely could have avoided it if we tested IPs and figured them out earlier in the semester.
One thing I was working on individually was Google Apps authentication for the wiki. I'll go into it more in a post about the wiki, but after setting it up I found that the feature wasn't enabled for WSU accounts. So we had to see if UTS thought that was a good feature to enable- I'll give an update once we get that up or not.
We had the IP addresses available to us for the virtual machines in advance, Dr. Wurst had asked about them earlier in the year for the server for the CS401 project so we were all set regarding those.
In one particular case we avoided UTS altogether. When we were moving the new CS server to production, we found that the old server wasn't assigned the public IP address directly- it was assigned a local IP address. This sounded like a 1:1 NAT set-up, which is essentially where you have local IP addresses for devices on your network and you route public IP addresses to certain IP addresses. So for moving the new CS server to production, we figured just changing the IP address from the old one over and giving the new server the old one's local IP address we'd be able to put it in production with no issues. We were able to do this and everything worked out well.
Overall I'd say working with UTS was a good thing. It definitely caused a bit of hassle as it wasn't really what I was used to, but overall a team like that is definitely a good thing to have.
I'm not really complaining, it's just a different experience. The most important takeaway is to plan out what you need in advance and send out requests as soon as possible. Some things will take more time than others as some tasks need to be verified to ensure network security and they definitely have other tasks to deal with than ours.
One big holdup we had was the networking for the cluster. It took Dillon and I a bit to figure out exactly what kind of networking we could do as well as what we wanted to do. The original cluster had one IP on WSU's LAN, and then a machine acted as a router and handled a separate LAN just for the cluster. We figured that wasn't really necessary and it would be easier enough to just have each machine with an IP on WSU's LAN instead. Initially we decided to just use the next 10 IP addresses from the block we were given for virtual servers. This set-up didn't work at all, and we figured those IP addresses were on a separate VLAN or something like that. Dillon later attempted to use the IP that was assigned to the server before but that didn't work. We could acquire IP addresses from DHCP, but we wanted some static IP addresses that we wouldn't have to worry about IP conflicts due to being in the DHCP pool or anything like that. We then had to ask UTS about getting some IP addresses, and while we waited we would just install the servers using the DHCP addresses. When UTS got back to us they told us that the whole block of the IP address that was given for the cluster before should be available, but we had already tested it and it didn't work, but we tested it again just in case and still it still didn't work. So we had to troubleshoot with them, and eventually we found out that the VLAN assigned to that port was wrong and got everything sorted out. It was kind of a hassle overall, but we definitely could have avoided it if we tested IPs and figured them out earlier in the semester.
One thing I was working on individually was Google Apps authentication for the wiki. I'll go into it more in a post about the wiki, but after setting it up I found that the feature wasn't enabled for WSU accounts. So we had to see if UTS thought that was a good feature to enable- I'll give an update once we get that up or not.
We had the IP addresses available to us for the virtual machines in advance, Dr. Wurst had asked about them earlier in the year for the server for the CS401 project so we were all set regarding those.
In one particular case we avoided UTS altogether. When we were moving the new CS server to production, we found that the old server wasn't assigned the public IP address directly- it was assigned a local IP address. This sounded like a 1:1 NAT set-up, which is essentially where you have local IP addresses for devices on your network and you route public IP addresses to certain IP addresses. So for moving the new CS server to production, we figured just changing the IP address from the old one over and giving the new server the old one's local IP address we'd be able to put it in production with no issues. We were able to do this and everything worked out well.
Overall I'd say working with UTS was a good thing. It definitely caused a bit of hassle as it wasn't really what I was used to, but overall a team like that is definitely a good thing to have.
by Jillur Rahman
Jillur Rahman is a Web designers. He enjoys to make blogger templates. He always try to make modern and 3D looking Templates. You can by his templates from Themeforest.
Follow him @ Twitter | Facebook | Google Plus
No Comment