Ever since I installed VMWare ESX server on my HP ML110 G4, I haven't got much chance playing it and it has been lying on the floor for a while...what a waste!
Recently I decided to convert it to my workstation pc and installed WIN2008 on it, so far I managed to add a USB sound card, install TV Tuner (Leadtek DTV 2000H) and managed to get it working after install the missing BDA component.
Now I am not quite satisfied with the CPU speed (Pentium D 810 2.8G) and the worst thing is, since it doesn't have HT I can't add Hyper-V to the server.
After doing some research, I found out that the server's documentation states that it supports xeon duo core 3000 , Pentium D CPUs but no quard core listed, I also found out similar Motherboards with same chipsets (Intel 3000/ICH7R) actually support Xeon Quad core 3200 CPUs.
After reading a post somewhere (in Japanese!) saying that Q6600 works with this server, together with the fact that Q6600 is identical to XEON X3200, I guess I will try to get one and see how it goes anyway. you gonna know that the benchmark score I got from a website shows Pentium D 2.8G gets 710 while for X3220 it is 2844!
Tuesday, March 31, 2009
Tuesday, March 10, 2009
Moving Database Files to different LUN under a SQL cluster environment
After managed to move quorum and DTC storage to different LUN, there is also the need to move database files around coz we need to do a SAN reconfiguration.
The highly summarized steps are as following:
> create new LUNs, present them to cluster nodes;
> initialize new disk, don't partition them yet, use diskpart to create partiton with an offset to make sure the partition is aligned.
> format new drives, assign drive letter, take SQL instance offline (leave the disk resource online), use xcopy to copy database files to the new drive.
>remove drive letter from the old drive, assign it to the new drive;
>using cluster administration tool, re-create the disk resource, modify resource dependency...
>failover and test etc.
The highly summarized steps are as following:
> create new LUNs, present them to cluster nodes;
> initialize new disk, don't partition them yet, use diskpart to create partiton with an offset to make sure the partition is aligned.
> format new drives, assign drive letter, take SQL instance offline (leave the disk resource online), use xcopy to copy database files to the new drive.
>remove drive letter from the old drive, assign it to the new drive;
>using cluster administration tool, re-create the disk resource, modify resource dependency...
>failover and test etc.
Thursday, March 5, 2009
HOWTO: Migrating Quorum and DTC drive to different LUNs for SQL Cluster
HOWTO: Migrating Quorum and DTC drive to different LUNs for SQL Cluster
1. Create two new LUNs for Quorum and DTC drives and present them to ESX Host;
2. Adding the new LUNs as raw disk mapping to cluster nodes using the same SCSI ID on all nodes;
3. Go to computer management and initialize the disks, create new partition and format them;
4. Move Quorum Drive to DTC temporally via cluster administration:
5. Go to disk management and remove the drive letter ‘Q:’, assign drive letter ‘Q:’ to the new disk that mapped to the new LUN, do this on all nodes;
6. Go back to cluster administration, add the new disk into ‘Cluster Group’ then assign the new drive as Quorum Resource;
7. The old quorum disk is now ready to be removed;
8. To move DTC storage, remove the DTC resource first, then delete the old DTC drive from DTC Group;
9. Remove the drive letter from old DTC Drive and assign it to the new DTC Drive;
10. Add the new DTC drive to DTC group;
11. Create DTC Resource and bind it to the new drive;
12. The old DTC Drive is now ready to be removed.
Notes: this is the actual steps I took to move quorum/DTC drive inside our environment, please be reminded that quorum and DTC sit on different drives here.
1. Create two new LUNs for Quorum and DTC drives and present them to ESX Host;
2. Adding the new LUNs as raw disk mapping to cluster nodes using the same SCSI ID on all nodes;
3. Go to computer management and initialize the disks, create new partition and format them;
4. Move Quorum Drive to DTC temporally via cluster administration:
5. Go to disk management and remove the drive letter ‘Q:’, assign drive letter ‘Q:’ to the new disk that mapped to the new LUN, do this on all nodes;
6. Go back to cluster administration, add the new disk into ‘Cluster Group’ then assign the new drive as Quorum Resource;
7. The old quorum disk is now ready to be removed;
8. To move DTC storage, remove the DTC resource first, then delete the old DTC drive from DTC Group;
9. Remove the drive letter from old DTC Drive and assign it to the new DTC Drive;
10. Add the new DTC drive to DTC group;
11. Create DTC Resource and bind it to the new drive;
12. The old DTC Drive is now ready to be removed.
Notes: this is the actual steps I took to move quorum/DTC drive inside our environment, please be reminded that quorum and DTC sit on different drives here.
SQL Server 2005 Cluster - Moving quorum/DTC drive
This exercise was done within VMWare ESX environment.
Notes:
-- this part relates to building the test environment
System drive (C:\) and shared drive need to sit on differenct scsi adapter
system drive need to sit on local disk resource (host storage)
map LUNs on nodes following same order and use same scsi id.
enable network dtc
'msdtc.exe -install' if things go wrong with MSDTC.
-- this part relates to moving quorum/dtc drive
>Break existing LUN to small LUNs: unmap the LUN from controller first then remove it, create new LUNs, map new LUNs to controller.
>check ESX storage controller and make sure new LUNs are presented to HOST.
--> add new LUNs to all nodes via raw disk mapping, make sure you use same SCSI ID on all nodes;
--> Move quorum drive to DTC drive temporally, release the drive letter from old quorum drive, assign it to the new drive, this need to be done on all nodes;
--> move quorum drive to the new disk;
--> for moving DTC drive, you will need to remove DTC first then add it back with the new drive;
Notes:
-- this part relates to building the test environment
System drive (C:\) and shared drive need to sit on differenct scsi adapter
system drive need to sit on local disk resource (host storage)
map LUNs on nodes following same order and use same scsi id.
enable network dtc
'msdtc.exe -install' if things go wrong with MSDTC.
-- this part relates to moving quorum/dtc drive
>Break existing LUN to small LUNs: unmap the LUN from controller first then remove it, create new LUNs, map new LUNs to controller.
>check ESX storage controller and make sure new LUNs are presented to HOST.
--> add new LUNs to all nodes via raw disk mapping, make sure you use same SCSI ID on all nodes;
--> Move quorum drive to DTC drive temporally, release the drive letter from old quorum drive, assign it to the new drive, this need to be done on all nodes;
--> move quorum drive to the new disk;
--> for moving DTC drive, you will need to remove DTC first then add it back with the new drive;
Monday, March 2, 2009
Moving quorum/MSDTC drive in a SQL server cluster environment
Moving quorum/MSDTC drive in a SQL server cluster environment
22 July from external source
Moving a Cluster to a New SAN
A fairly common scenario for a cluster administrator is to move a cluster from one SAN to another as SAN equipment is replaced with newer/faster SANs or the old SAN's lease is up and a new one is being brought in.
The easiest way that I have found to do this is to use these steps (this is from memory, let me know if I missed one or two):
Super High Level Steps:
1. Put the new array in the same fabric as the existing array
2. Create new LUNs on the new array and make sure they are visible to the nodes
3. Map the new LUNs to the old drive letters
4. Copy data from the old drive to the new drive
5. Move quorum and MSDTC
Slightly More Detailed Steps:
1. Carve the new LUNs on the new array
2. Add the new array and its LUNs to the same switch as the existing array
3. Configure the LUN masking on the switch to expose the new LUNs to NodeA and NodeB
4. Use the disk management tools in Windows to rescan the drives
5. Use the active node to partition and format the disks
6. Use Cluster Administrtor to create the new physical disk resources and put them into their proper cluster groups
7. Move the Quorum using the GUI to a temp location
1. In Cluster Administrator, right click the cluster name
2. Select Properties
3. Select the Quorum tab
4. Use the drop down box to select a temp location for the quorum
8. Delete the existing MSDTC folder (if any)
1. Stop the MSDTC resource
2. Copy the MSDTC folder from Q: to the final quorum disk target location
3. Stop the Q: resource (remember, the quorum isn't there anymore)
4. Delete the MSDTC resource
9. Move the quorum to its final location
1. Go into disk management and change the Q: name to another letter
2. Use disk management and name the final quorum drive to Q:
3. Repeat steps 1-4 to move the quorum to its final destination
10. Recreate the MSDTC resource
1. Create a new MSDTC resource with the clustername network name resource and the new Q: as dependencies
2. Bring the MSDTC resource online
11. Stop the cluster service and the application cluster groups (you can just stop the application resources if you want to move app data an app at a time)
12. Move the data from the old disks to the new ones
13. Re-letter the old disks to something outside the current range, but do not remove them yet - you might need to use them in your back out plan
14. Re-letter the new disks to the same drive letter as the old ones (no, you do not have to worry about disk signatures as applications don't understand disk signatures and don't care about anything other than drive letters)
15. Verify the dependencies and update them as needed
16. Restart the cluster service
17. Make sure the new drive letters and disk resources are showing up properly in cluster administrator
18. Bring everything back online
Again, these are basic steps. Some of the individual steps will require lots of work. I have done this now several times and am very happy with the results.
http://support.microsoft.com/default.aspx?scid=kb;en-us;280353
Fom: http://msmvps.com/blogs/clusterhelp/archive/2005/08/05/moving-a-cluster-to-a-new-san-original-posted-jul-22-2005.aspx
22 July from external source
Moving a Cluster to a New SAN
A fairly common scenario for a cluster administrator is to move a cluster from one SAN to another as SAN equipment is replaced with newer/faster SANs or the old SAN's lease is up and a new one is being brought in.
The easiest way that I have found to do this is to use these steps (this is from memory, let me know if I missed one or two):
Super High Level Steps:
1. Put the new array in the same fabric as the existing array
2. Create new LUNs on the new array and make sure they are visible to the nodes
3. Map the new LUNs to the old drive letters
4. Copy data from the old drive to the new drive
5. Move quorum and MSDTC
Slightly More Detailed Steps:
1. Carve the new LUNs on the new array
2. Add the new array and its LUNs to the same switch as the existing array
3. Configure the LUN masking on the switch to expose the new LUNs to NodeA and NodeB
4. Use the disk management tools in Windows to rescan the drives
5. Use the active node to partition and format the disks
6. Use Cluster Administrtor to create the new physical disk resources and put them into their proper cluster groups
7. Move the Quorum using the GUI to a temp location
1. In Cluster Administrator, right click the cluster name
2. Select Properties
3. Select the Quorum tab
4. Use the drop down box to select a temp location for the quorum
8. Delete the existing MSDTC folder (if any)
1. Stop the MSDTC resource
2. Copy the MSDTC folder from Q: to the final quorum disk target location
3. Stop the Q: resource (remember, the quorum isn't there anymore)
4. Delete the MSDTC resource
9. Move the quorum to its final location
1. Go into disk management and change the Q: name to another letter
2. Use disk management and name the final quorum drive to Q:
3. Repeat steps 1-4 to move the quorum to its final destination
10. Recreate the MSDTC resource
1. Create a new MSDTC resource with the clustername network name resource and the new Q: as dependencies
2. Bring the MSDTC resource online
11. Stop the cluster service and the application cluster groups (you can just stop the application resources if you want to move app data an app at a time)
12. Move the data from the old disks to the new ones
13. Re-letter the old disks to something outside the current range, but do not remove them yet - you might need to use them in your back out plan
14. Re-letter the new disks to the same drive letter as the old ones (no, you do not have to worry about disk signatures as applications don't understand disk signatures and don't care about anything other than drive letters)
15. Verify the dependencies and update them as needed
16. Restart the cluster service
17. Make sure the new drive letters and disk resources are showing up properly in cluster administrator
18. Bring everything back online
Again, these are basic steps. Some of the individual steps will require lots of work. I have done this now several times and am very happy with the results.
http://support.microsoft.com/default.aspx?scid=kb;en-us;280353
Fom: http://msmvps.com/blogs/clusterhelp/archive/2005/08/05/moving-a-cluster-to-a-new-san-original-posted-jul-22-2005.aspx
Subscribe to:
Posts (Atom)
Elevating LLM Deployment with FastAPI and React: A Step-By-Step Guide
In a previous exploration , I delved into creating a Retrieval-Augmented-Generation (RAG) demo, utilising Google’s gemma model, Hugging ...
