1. No Android Market. All apps are downloaded via Amazon Market which is their own version of the main Android Market and community.   The Amazon Market has but a small fraction of the apps available.  I think this is so because of the tailored version of the Kindle OS.  It seems more likely that an app on Android Market will not work correctly on a fire and that is why they excluded Android Market from the Fire.  However, if you have some time and tech skills, you can root the device and install Android Market.  For example, the Android version of WordPress is not compatible.  Some will work – some will not.  See below to root.

2. No corporate email. Amazon has excluded Activesync for Corporate Exchange Email Systems.  While there are apps available for download, that poses a problem for corporate admins and that is lack of device management.  When Activesync is tightly coupled into the device OS, IT administrators can remotely manage the device and even remotely “burn the B” with a remote wipe feature in case its lost.  And devices are lost all the time.

So for right now, the Fire seems perfect for a consumer and could be a terrific opportunity to get in and duke it out with Apple.  Based on the success this holiday season, it would not surprise me if a different version is available in the future that contains additional corporate features.

BAM! – Yes – You can root it and install Android Market and also install a corporate email app.  I have done that with mine.  It was kind of a pain.  Amazon updated to v6.21 as I recived mine and the orginal set of instructions worked 80%.  I was not able to move the Vendor.apk file (Market app) to the /system/app folder on the fire as outlined in the original instructions.  then I found out I had downloaded the wrong version, it was a very old one, so I had two issues.  I was able to get the latest v3.11 of the Vendor.apk and move the file to the /system/app directory.  I messed around quite a bit so I am not sure exactly the order.  But below find some helpful URL/tools to get you pointed in the right direction.

• This is the original root instructions updated for v6.21.
• This is another way.  I use this to gain access via adb (dev tools) (its similar to above)
• Working Vendor.apk (if you need it)

Now if you follow these instructions you should be good.  If not, google around for errors and try different things.  For me i gained root access and pushed the Vendor.apk to the /system/app directory.  Trying to move any other way, gave me some crazy cross link error, even when I mounted the fs RW.  So you need to just try a few things of the original instructions do not work.

Finally, try the app Moxier Mail for an Exchange compatible email app.  Its free for 14 days then $20.

Good Luck.  TS-Admin

Flat network.

• Pro-Simpler
• Pro-Less Complex
• Pro-Less expensive – No routers
• Pro-One network domain – Everyone hears everyone
• Con-Susceptible to broadcast storms or single nic errors which can cause issues for the entire network.
• Con-One network domain – Everyone hears everyone.  This can also be a disadvantage.

VLAN Network

• Pro-Versatile – Vlan’s can be separated by access lists for improved security
• Pro-Distance – Vlans’s overcome 100m distance limitations common in larger installations.
• Pro-Creates broadcast domains between Vlans and that helps with broadcast and nic issues.
• Con-Expensive.  You need routers and more devices to create a sound network.
• Con-Complex.  You need more skills and experience.

Which one is right for me?  Depends?  If you need to separate traffic for any reason, then yes, you may need multiple vlans.  Separating traffic is handy for various reason.  You can separate telephone and video traffic from regular PC traffic.  Put them on separate vlans.  This way you may have a better opportunity to outlast a pc/desktop issue that is causing performance traffic on the pc/desktop vlan.  This way you are saying you want your phones to work no matter what.  Now there are other items you must do to ensure that actually occurs, but one thing is certain.  If they are all on a single network (no vlans) and that network is hosed.  Then everything is hosed.  Separating traffic to vlans will many times help mitigate these types of outages.

So for me.  I will try and get my phones on a separate vlan and see how it goes.  Its more complex, but I want to give it a try.

The Network.  Before we work on any servers, install any phones, etc, we need a solid network.  Most of the time I see folks trying to identify the least expensive server and/or network devices.  However in my world, Corporate Enterprise, here lies the problem.  These are the items that fail most often.  So at a minimum.  You want two switches.  it would also be best if you do not chince out and get the least expensive one.  You need one with “Spanning Tree Protocol” (STP).  Why STP?  Because STP is what helps prevent loops in a switched network.  And we are going to create a loop on purpose and we want STP to stop it when we want it stopped, and enable links when we experience a failure.  Check out the following sites on Spanning Tree Protocol.

http://en.wikipedia.org/wiki/Spanning_Tree_Protocol

http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/sw_ntman/cwsimain/cwsi2/cwsiug2/vlan2/stpapp.htm

So check out the following diagram

This is the basis for a simple and solid network.  Two switches.  Both running Spanning Tree.  Take a look at the two red cables.  They plug into the last port on each switch and plug in to the corresponding port on the 2nd switch.  Now if I plug one cable in, that is ok.  It simply is connecting the first switch to the second.  Normally we are ok here.  Now when we plug the second cable connecting the two switches together, we cause a “Loop”, and it will immediately cause the network to fail.  No traffic will pass.  Loops in a switched network = BAD = the worst thing you can do.

But sometimes we want loops.  Actually we want loops quite a bit.  Why?  Because we want path redundancy.  We always want multiple paths to get to where were want to go.  But in a switched network, one without a router in between, that would cause a loop, and we want STP to identify the best path, and close off the slowest path.  But be ready just in case there is a path problem, and then jump in and find another path.  All the while while not causing a loop.

So in our example, we want STP to detect the loop and automatically set one of the ports to “not forward” any traffic.  This way we can have multiple paths on our small switched network.  This is the redundancy we are now starting to look for.

Finally, notice the Asterisk servers with the GREEN links.  Normally we see a server with two NICS like this and its ok.  And we could connect the servers with two NICS, but we would have to have two IP addresses.  That would not work with Asterisk.  Why?  Because the phones are configured to use a single IP address with Asterisk.  Now some can use a backup IP, but we have two servers and that would be 2X2=4 IP addresses.  Now we are getting complicated.  We want to make this simpler and easy to recover from a failure.  Not more complicated.

Where are we going with this? Well I’ll tell you.  What if we could get each server to use both of it’s NICS and use only one IP?  Now we are talking.  Now we have gone from 4 IP’s to 2.  Finally, what if we could get each server to have a single virtual IP, and they both decide who is going to be the IP?  And it is in a coordinated fashion.  So if PBX1 is running the Asterisk server, and it has any type of hardware failure, or Switch #1 fails, or anything like that.  Then PBX2 automatically takes over the virtual IP.  That would be cool.  This way you could recover from a server failure or recover from a switch failure.  Automatically!   Now in some situations, especially with a switch failures, some of the phones connected to the switch are down.  That is the cool part of this.  You have 1/2 your phones/users on one switch and the other half on the other one.  You not all down.  Only partially down.  And that could make the difference of being in a bad spot the entire day, or just a blip in the radar for the day.  It’s all how you look at it.

Next Post will be how to configure the Asterisk server to use two NICS but only have one IP address. And we will connect each NIC to a separate switch.  This is called “bridging” and will be the next post.  Check back later.

PROS

• Small, lightweight, and compact
• Wired and Wifi
• HDMI
• Works with Netflix, Hulu, Pandora, MP3Tunes, and Amazon Video.  Nice combination if sites to play/rent video and music from.
• Inexpensive.  $59-$99.  Got a Roku XD for $69 and free shipping from Amazon.  Plus it includes 10Gb of music storage from MP3Tunes.

CONS

• Missing Component Video + Audio. (Actually only on the $99 unit)
• Missing ability to easily stream music from local network or local PC.  You can use a USB port on the $99 unit.

Overall I like it a lot.  The remote is basic and works fine.  I can browse and search for TV shows on Hulu and rent movies and shows on Amazon and Netflix.  It runs 1080p and look good on my TV’s.

http://news.cnet.com/8301-27080_3-20012386-245.html?part=rss&tag=feed&subj=InSecurityComplex

is a good article on the vulnerability.

How do you keep it cool?  There are many ways to keeping these areas cool.  And unfortunately some work, and many do not, and not everyone knows how.  Most professional engineers (PE) can keep a small IT space cool.  But throw in a cabinet with unique cooling requirements, shape the room a little weird, or just plain have significant cooling requirements, it all goes out the window. You need a PE with data center experience.  You need a GC with data center experience.  You need a mechanical firm with data center experience.  In other words, data centers are not run of the mill stuff.  So unless you are not interested in 24/7, you need specialized partners who know how to work in a LIVE data center.  Because once it is built, there will be changes, and most people can not shutdown a data center.  I know we can not.  And if it’s not done right the first time.  Then you get to do it all over again.

Over the next few months, I’ll post on a project where we did all of the following.  With no downtime!  Lots of planning  and coordination.  It was a bunch of all nighters and lots of weekend work.  But the payoff was worth it. We have awesome data center and it’s exactly what we wanted from day one.  Just took us longer to get it.  Almost two years.  Most was done in the 1st year, but end to end it was two years.  The key was no downtime.  downtime=bad=resume generating event!  DOOH!

In a nutshell we….

1. Moved into a newly acquired and renovated building.  Part of the renovation was the built out of a new data center.  Noticed numerous hot spots within the data center at approximately 1/3 of the room’s load.  Not a good first sign.
2. After going live, we analyzed the data center and figured out we had issues with the cooling system.
3. We hired another PE, not the one who did the original design, and we identified the issues.
4. The computer room air handlers (CRAH’s) were undersized and in the wrong spot.  Air was not moving where we needed it.  The hot air was mixing with the cool air.
5. The PE’s report was excellent and we formulated a new plan.
6. Built a new mechanical room next to the data center.
7. Built a new chilled water supply and return to the mechanical room.  Tied it into the existing riser.
8. Installed two new CRAH’s.
9. Installed new supply ducting.
10. Created a common header for the chillers.
11. Added a new pump to the chillers supplying the cold water.
12. Now the cold air and hot air were moving as expected.  Hot spots are gone.
13. Tied everything into the existing fire control system.  Tested it.
14. Installed a new building management system just for the critical IT systems.

I am tired just typing it.  But it was worth it.

]]> http://www.datacenterlife.com/2010/08/01/keeping-it-cool-the-mechanicals/feed/ 0 http://www.datacenterlife.com/2010/07/29/microsoft-azure-life-in-the-cloud/ http://www.datacenterlife.com/2010/07/29/microsoft-azure-life-in-the-cloud/#comments Thu, 29 Jul 2010 19:53:37 +0000 Ts-admin http://www.datacenterlife.com/?p=185 I had a chance to view the Microsoft Azure platform last night.  It was presented by the DC DotNet Users Group in Washington DC.  I am quite familiar with both Google and Amazon cloud’s and the advantages, and disadvantages with them.  For my enterprise, they are not very helpful as we are a 100% Microsoft shop and run tons of apps, both off the shelf, and custom .asp/.net.  So most clouds are difficult for us for the following reasons.

1. Can not install .exe or .msi apps and run out of the box.  Most clouds require some proprietary process for getting apps created and uploaded to the cloud.  Kinda like creating an image for a desktop/laptop.  There is a process to follow and you have rules to follow or you end up with a messed up image.
2. Because of the proprietary nature, it requires changes in internal processes, additional training, and plain just changing the way you do stuff.  It also requires you to conform to the cloud and you possibly loose flexibility.
3. Linux – Open source based.  We are a Microsoft shop, so the application-development team would have to switch or create and maintain two code bases.  Neither is attractive for us.

Now comes Azure from Microsoft.  It has been out since January and building some steam.  Here are the pros!

1. Its all Microsoft Stuff.  Yeah.
2. No need to procure Microsoft licenses.  Its all built into the costs.
3. Developers will like it.  Create apps for in-house or the cloud.  If you do it right, you can deploy either.
4. Typical cloud.  Spin up virtual servers pretty quickly.  Networking, firewalls, load balancing, etc all built in.
5. Geo-location.  You can scale to multiple data centers pretty easily.  Just costs more.
6. TCO is ok.  Scalability is key.  Just depends on your requirements.  No CAPEX.  All Expense!

Now the cons.

1. While its all Microsoft software.  Its not the same.  There are lots of limitations.  You can not tweak most of the stuff you want to tweak.
2. No installing .exe or .msi’s like you do on a standalone boxes or VM’s.
3. No access to IIS configs.  No access to registry.  No access to boot drives.
4. Azure VM boxes are throw away’s.  You need to store code and temp stuff on some type of storage.  So if you do certain things now, you have to learn the cloud way.  This is likely to be painful the first few deployments, upgrades, mistakes, etc.  I have it down now, but now I need to learn the cloud way.  Its new and you will need to learn it.
5. Costs.  Can get expensive.  You pay for everything.  Development, staging, production environments all cost $$ as they need to be running.  So if you run a typical three tier environment, it all adds up, and that erodes the cloud TCO compared to running in-house.

It would be tough for us to use Azure at this time.  We use a lot of off the shelf applications and tools.  No way to install into the cloud.  Applications want to install and modify the local drives, copy files, change the registry, and all that is not cloud compatible.  I am sure if we could redo some apps, start all over with the latest development tools and develop for the cloud, then that may be an option, but it would require a wholesale redo of an application.  Given available resources, its not likely, nor is it cost effective.

Why?  Because we do data center stuff pretty good and we concentrate on availability.  The big advantage is DR/BCP.  The cloud could certainly could help us there.  But our largest web apps are not suitable for the cloud, because they are built on a third party applications, so its not really an option.  There are some suggestions for putting Exchange and IM in the cloud and somehow reducing CAPEX costs.  Not really!  We do it pretty good and we also integrate Exchange and IM with voicemail, Blackberry’s, and mobile devices.  Shortly we will step it up and integrate with our Cisco phone and Tandberg video platforms.  So outsourcing Exchange and IM to the cloud, would be painful given our integration points, and certainly make it more complex and expensive.

My $.02 on the Azure cloud.  But it will change and improve over time.  I will certainly keep an eye on it.  Ts-Admin.

Now find the “Navisphere Storage System Initialization Utility” CD.  Initializing allow you to access the array from the networking using a web browser.  It may be on the server support CD or may be the CD that says “install me first”.  Follow the instructions that say install products on server.

1. Connect each SP to a very basic network switch.  Nothing special, just a 10/100/ switch, and connect your laptop to it.  Give your laptop an IP address.  Anyone will do.  The array and laptop need to be on the same physical subnet.
2. Start the Initialization Utility: Start, Programs, EMC, Navisphere, Navaisphere Storage System Initialization.
3. The utility will automatically search for uninitialized storage systems.  They are identified by serial number.  Check the back of your CX4 and verify.  Especially if you did not do #1 and have it connected to your network.
4. Select the serial number from the Uninitialized Systems list.  Provide the information the utility requests.  It is all IP address stuff.  Use the IP addresses that you want to use once you have it connected to your network.
5. It likely will want to reboot the array.  Let it.
6. Connect the array and your laptop to your network.  Update the IP on your laptop if necessary.  Pull up a browser and browse to the IP address of SPA.  You should get Navisphere login.  Go a head and browse to SPB.  You should get a Navisphere login.
7. Register your array!

BAM!  Your ready for the next steps.  Which is to update the array with any patches and/or enable additional software.   More on both in a later post.

1. Shutdown the box and took a snapshot from the VM Client.  This allows me to fall back to this point in time.
2. Boot the server.
3. Using a web browser, I backed up the database.  WP uses MYSQL.  So I logged on to MYSQL via PHPMYADMIN.  This is an optional application and makes management simple.  From there I backed it up to my desktop.
4. I accessed the blog admin page and disabled all plugin’s.  This is recommended.
5. I downloaded the wp3.0 file and moved the file to the server.  I unzipped to a temporary directory.  I also created an archive of the existing installation.  I now have everything I need to also fall back another way.  I can copy the existing install back and restore the DB.  Or I can use VM to fall back in time.
6. I followed the guide and deleted most files in the root of the site and also some folders.  I left a few files in place.  Again, the guide provides specific instructions.
7. I copied the WP files to the roof of my web server.
8. I ran the DB upgrade script.  Success!
9. I accessed the blog and checked the admin site.  All is good.
10. I activated the plugins.
11. Two plugins needed upgrading.  I upgraded and tested.
12. While I was here, I added a social network plugin.  I tested and its all good.
13. Finally, updated the server OS with a few application upgrades and patches.
14. Rebooted.  Tested.  Done.

I will run it for a week and then remove the VM snapshot.  It will also get backed up as a complete VM by one of our backup servers.  I can now restore this as a new VM at anytime and restore the entire site within an hour.  VM’s are great for this.