Well, it appears that there are not cheap iSCSI drives (or gigabit drive enclosures) out there. Sure there are NPWR and Adaptec, but both of those solutions are $700/drive.
Which is wierd, since cases are usually around $20 and the drives (250GB Samsung) were only $52 and the OS (NetBSD or Linux) is free...
I was looking at possibly making my own via mini-itx or something. Found iSCSI-SCSI bridges (only $1200)...
maybe it is time to make my own...? well, I would, but I really don't have the time to experiment right now... so I guess I once again have to get a larger server box up and running; then take my time designing my iSCSI solution (rotozip must like the enclosures)... And THEN design my nice small cool (as in temp) server....
In the meantime, got to figure out what to do... build new AMD-V machine (which isn't on Solaris HCL) or convert the last machine I bought (that has memory controller bugs and Asus lies all over it)
Showing posts with label AMD-V. Show all posts
Showing posts with label AMD-V. Show all posts
30 January 2007
29 January 2007
23 January 2007
Thoughts... ie: What should I do?
So as I investigate things like Sun servers, OpenSolaris, ZFS/Raid-Z, iSCSI, Embedded NetBSD, etc etc... I start thinking that perhas a better approach would be to start off with a list of requirements... It is a little late to "start" there, but, what the hell...
* We do not want a repeat of the data wipeout we got a year ago... As such, if one domain gets hacked, it can not take down the rest of the domains.
- I had been planning on using Jail to alleviate this problem, but at this point I think our best bet is Xen
- While many OSs support Xen domU, many fewer support Xen dom0.
* Also, if a domain gets hacked and wiped out, we need a backup to restore from.
- ZFS Snapshots (maybe full weekly and incremental daily) seems like a good solution for this
- SVN might be a good solution to this
- It might be good if there was a way to automate this (ie: allow the root user to do it instead of emailing me)
* We want to get disk redundancy, while keeping cost and maintenance low.
- RAID-0 gives us the redundancy, but at a fairly high cost. The current 1TB gives us less than 500GB this way.
- RAID-5 could be acceptable, as long as we could fix the system if the root partition were the one to screw up
- ZFS and Raid-Z seem like excellent options to provide the redundancy and automatic corrections
* Each domain should be able to have it's own root user and OS.
- Jail could have provided for this, but seems very buggy ('man man' in a jail crashed the entire OS)
- Xen should allow for this fairly easy. As such, the base OS really doesn't do anything other than launch the domUs.
* If multiple OSs share a base OS, it would be nice (though not required) if we were able to not waste a lot of duplicated space
- Unionfs is ideal for this. Not sure how easy it is to use with Xen
- At some point, it has to be better to have a full copy (like if they upgraded every single app)
* It would be preferable if all OS's could run unmodified, thus allowing us greater flexibility and choices
- Intel VT or AMD-V technology. If we are planning on doing any RSA work on any domain, it can't be the Intel option. So probably an Opteron 2xxx (or 2).
* If we run low on drive space, it should be fairly simple to add more
- ZFS is supposed to allow for this with 'zfs add'
- We *could* do separate drives for each domain, but that would waste a lot of drive space
- iSCSI might be a better option than internal drives for this. Instead of running out of hard drive bays, we'd just have to worry about running out of ethernet ports -- which realistically, is much easier to come up with more of. ** SEE BELOW
** iSCSI Thoughts:
- IDEALLY, I would have a set of cheap 250GB or 500GB drives that host themselves as iSCSI Targets. Then, adding new drives is literally adding another drive to the network.
- We could, in theory, run Solaris or NetBSD to easily provide iSCSI Targets to the network - but then we have to wonder why we are creating a separate box to host Xen
- If we have multiple iSCSI Targets, which our Solaris(?) box were to RAID-Z together, we could also have extra iSCSI Targets that VMWare and/or other hardware could use directly (even Windows)
- If we have multiple iSCSI Targets, which our Solaris(?) box were to RAID-Z together, the Solaris box could provide the pool as a iSCSCI Target to other devices/OSes
- If we were to have Solaris running RAID-Z directly on the iSCSI Target (ie: providing ZFS pools as iSCSI Targets), then separate Xen domUs could point to these iSCSI Targets for their primary data storage and POTENTIALLY get the ZFS benefits regardless of their OS (snapshots, error-correction [at least from hardware errors], etc)
- In theory, if we could come up with mini embeddable systems that could boot from iSCSI Targets, then we could do away with Xen entirely and just have a little device on the network for each domain... this might be overkill
- Note: Can Solaris boot off iSCSI?
* We do not want a repeat of the data wipeout we got a year ago... As such, if one domain gets hacked, it can not take down the rest of the domains.
- I had been planning on using Jail to alleviate this problem, but at this point I think our best bet is Xen
- While many OSs support Xen domU, many fewer support Xen dom0.
* Also, if a domain gets hacked and wiped out, we need a backup to restore from.
- ZFS Snapshots (maybe full weekly and incremental daily) seems like a good solution for this
- SVN might be a good solution to this
- It might be good if there was a way to automate this (ie: allow the root user to do it instead of emailing me)
* We want to get disk redundancy, while keeping cost and maintenance low.
- RAID-0 gives us the redundancy, but at a fairly high cost. The current 1TB gives us less than 500GB this way.
- RAID-5 could be acceptable, as long as we could fix the system if the root partition were the one to screw up
- ZFS and Raid-Z seem like excellent options to provide the redundancy and automatic corrections
* Each domain should be able to have it's own root user and OS.
- Jail could have provided for this, but seems very buggy ('man man' in a jail crashed the entire OS)
- Xen should allow for this fairly easy. As such, the base OS really doesn't do anything other than launch the domUs.
* If multiple OSs share a base OS, it would be nice (though not required) if we were able to not waste a lot of duplicated space
- Unionfs is ideal for this. Not sure how easy it is to use with Xen
- At some point, it has to be better to have a full copy (like if they upgraded every single app)
* It would be preferable if all OS's could run unmodified, thus allowing us greater flexibility and choices
- Intel VT or AMD-V technology. If we are planning on doing any RSA work on any domain, it can't be the Intel option. So probably an Opteron 2xxx (or 2).
* If we run low on drive space, it should be fairly simple to add more
- ZFS is supposed to allow for this with 'zfs add'
- We *could* do separate drives for each domain, but that would waste a lot of drive space
- iSCSI might be a better option than internal drives for this. Instead of running out of hard drive bays, we'd just have to worry about running out of ethernet ports -- which realistically, is much easier to come up with more of. ** SEE BELOW
** iSCSI Thoughts:
- IDEALLY, I would have a set of cheap 250GB or 500GB drives that host themselves as iSCSI Targets. Then, adding new drives is literally adding another drive to the network.
- We could, in theory, run Solaris or NetBSD to easily provide iSCSI Targets to the network - but then we have to wonder why we are creating a separate box to host Xen
- If we have multiple iSCSI Targets, which our Solaris(?) box were to RAID-Z together, we could also have extra iSCSI Targets that VMWare and/or other hardware could use directly (even Windows)
- If we have multiple iSCSI Targets, which our Solaris(?) box were to RAID-Z together, the Solaris box could provide the pool as a iSCSCI Target to other devices/OSes
- If we were to have Solaris running RAID-Z directly on the iSCSI Target (ie: providing ZFS pools as iSCSI Targets), then separate Xen domUs could point to these iSCSI Targets for their primary data storage and POTENTIALLY get the ZFS benefits regardless of their OS (snapshots, error-correction [at least from hardware errors], etc)
- In theory, if we could come up with mini embeddable systems that could boot from iSCSI Targets, then we could do away with Xen entirely and just have a little device on the network for each domain... this might be overkill
- Note: Can Solaris boot off iSCSI?
16 January 2007
EMail conversation with Sun
I received this email....
So the rest will most likely be via phone.
Hi Malachi,My response:
Thank you for visiting the web chat forum on the Sun website yesterday, when you expressed interest in the Try and Buy promotion being currently run by Sun.
You mentioned that you are deciding which machine you will trial on the promotion - excellent! You will see the full list of products on the promotion at www.sun.com/tryandbuy
You can email me with any questions that you may have, or you can visit our team at the web chat forum. Here's some additional information on the Try and Buy promotion, which you may find useful:
When you receive the Server on the Try and Buy promotion you will also receive a Welcome Pack.
Inside the Welcome Pack you will find-
1. A Quick Guide to Installation.
2. Access to Tuning and Optimization documentation.
3. Access to an online portal and forum for system and application tuning hints and tips.
4. Access to Sun's performance engineers.
5. All of the latest patches and configuration files for the system on the portal.
Additional options for purchase are available for system ready and business ready services.
The Solaris 10 Operating System and other software provided with the system is covered under the Warranty support during the Try and Buy period.
Best Regards
Mark Cradock
Sun Microsystems
Tel: + 353 (0)599136768
mark.cradock@your-sun.com
www.sun.com
Hi Mark,
I am debating the Sun Fire X4200 or the Sun Ultra 40 Workstation. Perhaps it would be better for me to explain the intended usage and get your feedback.
First, a little background. We had a FreeBSD box running for about 4 years without reboot. As is probably obvious from that statement, we were behind on the security updates. While we were hosting multiple domains, they were not in Xen or Jail or anything. On Christmas eve a year ago, a hacker from a Polish cable isp hacked in through one of the user accounts and wiped out the entire system. Because of this, I decided this time that I wanted to ensure that the various domains stay secure even if one is compromised.
We bought the latest top-of-the-line Asus, AMD, etc. Unfortunately, AMD lied about the capabilities of the board. They said it was capable of RAID-5 on SATAII, but in actuality it is capable of RAID-5 OR SATAII. Then we installed FreeBSD-CURRENT, and found out it doesn't support RAID-5 yet. Needless to say, it has been a hassle.
So we are debating buying a Sun server and running Solaris on it. My expectation is that there should not be any driver compatibility problems at that point.
So long story not so short -- we are looking at trying to run a bootable RAID-Z (yes, I know that requires some tweaking, but I want to ensure that the boot is also recoverable) with a Xen Dom0. On top of that, we want to allow each domain to run its own OS (whichever they choose, thus prefer AMD-V) as a DomU. Based on this, I think that each DomU would get the advantage of Raid-Z on the underlying filesystem, even if they didn't know about it directly, and regardless of which OS they are running.
Do you have any thoughts, concerns, or questions?
Malachi
A followup:
Hi Malachi,
First of all, sorry to hear about the experiences you've had with the FreeBSD and Asus! Not good.
Secondly, one of the reasons for the Try and Buy promotion is that you can test the capabilities of each machine prior to actually buying it. I'm sure that you will have a positive experience and benefit from this.
I would recommend that we assign a server specialist to you, that can be available prior to your choice of machine, and also be available for you right through the trial process to assist you in your testing, additional components, adjustments in configurations, etc. Would you have a
contact number that we can call you on?Best Regards
Mark Cradock
Sun Microsystems
Tel: +
353
(0)599136768
mark.cradock@your-sun.com
www.sun.com
So the rest will most likely be via phone.
16 December 2006
Top of the line AMD Processors
I have not yet figured out what the difference between these are... except $2k.
Or we can go with the 2.4GHz and get the low-power version...
| Processor Details | ||
| CPU ID | Next-Generation AMD Opteron™ Processor Model 8220 | Next-Generation AMD Opteron™ Processor Model 2220 |
| Model | 8220 SE | 2220 SE |
| Ordering Parts Number (OPN) | OSY8220GAA6CR | OSY2220GAA6CQ |
| Stepping | F2 | |
| Frequency | 2.8GHz | |
| HT Speed | 1000MHz | |
| Integrated Memory Controller | 2.8GHz | |
| Core Voltage | 1.325 V/1.375 V | |
| Case Temperature | 55°C to 69° C | |
| Wattage | 119.2W | |
| L2 Cache Size | 2 MB | |
| L2 Cache Speed | 2.8GHz | |
| Manf. Technology | .09 micron SOI | |
| Socket | Socket F (1207) | |
| Amperage | 86.9 A | |
Or we can go with the 2.4GHz and get the low-power version...
| Processor Details | |||
| CPU ID | Next-Generation AMD Opteron™ Processor Model 8216 | Next-Generation AMD Opteron™ Processor Model 2216 | |
| Model | 8216 HE | 2216 HE | |
| Ordering Parts Number (OPN) | OSP8216GAA6CR | OSP2216CQWOF | OSP2216GAA6CQ |
| Stepping | F2 | ||
| Frequency | 2.4GHz | ||
| HT Speed | 1000MHz | ||
| Integrated Memory Controller | 2.4GHz | ||
| Core Voltage | 1.20 V/1.25 V | ||
| Case Temperature | 55°C to 72° C | ||
| Wattage | 68.0W | ||
| L2 Cache Size | 2 MB | ||
| L2 Cache Speed | 2.4GHz | ||
| Manf. Technology | .09 micron SOI | ||
| Socket | Socket F (1207) | ||
| Amperage | 53.3 A | ||
| Remove Item | Remove Item | Remove Item | |
14 December 2006
Virtualization Support in Athlon 64
Athlon 64 FX models
Windsor (90 nm SOI)
Dual-core CPU
- CPU-Stepping: F2
- L1-Cache: 64 + 64 KiB (Data + Instructions), per core
- L2-Cache: 1024 KiB fullspeed, per core
- MMX, Extended 3DNow!, SSE, SSE2, SSE3, AMD64, Cool'n'Quiet, NX Bit, AMD Virtualization
- Socket AM2, 1000 MHz HyperTransport (HT1000)
- VCore: 1.30 V - 1.35 V
- Power Consumption (TDP): 125 Watt max
- First Release: May 23, 2006
- Clockrate: 2800MHz (FX-62)
Windsor (90 nm SOI) - Quad FX platform
Dual-core, dual CPUs (four cores total)
- CPU-Stepping: F3
- L1-Cache: 64 + 64 KiB (Data + Instructions), per core
- L2-Cache: 1024 KiB fullspeed, per core
- MMX, Extended 3DNow!, SSE, SSE2, SSE3, AMD64, Cool'n'Quiet, NX Bit, AMD Virtualization
- Socket F (1207 FX), 1000 MHz HyperTransport (HT1000)
- VCore: 1.35 V - 1.40 V
- Power Consumption (TDP): 125 Watt max per CPU
- First Release: November 30, 2006
- Clockrate: 2600MHz (FX-70), 2800MHz (FX-72), 3000MHz (FX-74)
Athlon 64 models
Orleans (90 nm SOI)
- CPU-Stepping: F2
- L1-Cache: 64 + 64 KiB (Data + Instructions)
- L2-Cache: 512 KiB, fullspeed
- MMX, Extended 3DNow!, SSE, SSE2, SSE3, AMD64, Cool'n'Quiet, NX Bit, AMD Virtualization
- Socket AM2, 1000 MHz HyperTransport (HT1000)
- VCore: 1.35 V or 1.40 V
- Power Consumption (TDP): 62 Watt max
- First Release: May 23, 2006
- Clockrate: 2000 - 2400 MHz
AMD virtualization (AMD-V)
AMD's virtualization extension to the 64-bit x86 architecture is named AMD Virtualization (also known by the abbreviation AMD-V), and is sometimes referred to by the code name "Pacifica".
AMD processors using Socket AM2, Socket S1, and Socket F include AMD Virtualization support. In May 2006, AMD introduced such versions of the Athlon 64 and Turion 64 processors. AMD Virtualization is also supported by release two (x2xx series) of the Opteron processors.
Xen 3.0 Supports AMD-V/Pacifica
With hardware CPU virtualization as provided by Intel VT and AMD Pacifica technology, the ability to run an unmodified guest OS kernel is available. No porting of the OS is required, although some additional driver support is necessary within Xen itself. Unlike traditional full virtualization hypervisors, which suffer a tremendous performance overhead, the combination of Xen and VT or Xen and Pacifica technology complement one another to offer superb performance for para-virtualized guest operating systems and full support for unmodified guests running natively on the processor. Full support for VT and Pacifica chipsets will appear in early 2006.
Subscribe to:
Posts (Atom)