|
It's not like a 1u 1socket 8gb ram 250gb raid1 server with ipmi costs all that much. If i'm in the middle of a catastrophic vmware cluster event, the last thing I need to be stressed about is having a copy of the global catalog and basic dns resolution along with everything else going on at the time. It's cheap peace of mind for that exact scenario.
|
#
?
Mar 11, 2016 20:43
|
|
|
|
| # ? Jun 9, 2024 19:38 |
|
|
We have 6 DCs, 2 physical and 4 VMs spread across 2 datacenters. The physicals are only there in the event that 1) Our hyper-V clusters go down (3 hosts per datacenter) and 2) the network link to the other datacenter is down. If both of those events happen, the DCs will not be able to authenticate against anything and poo poo gets bad. The physical DCs are actually our backup servers with a small portion cut off to act as a DC in the event of disaster.
|
|
#
?
Mar 11, 2016 21:09
|
|
|
I'm struggling to think of anything you can do with a physical DC that you couldn't also do with a virtual DC (in addition to the other things you can only do with a virtual server).
|
|
#
?
Mar 11, 2016 21:17
|
|
|
devmd01 posted:It's not like a 1u 1socket 8gb ram 250gb raid1 server with ipmi costs all that much. If i'm in the middle of a catastrophic vmware cluster event, the last thing I need to be stressed about is having a copy of the global catalog and basic dns resolution along with everything else going on at the time. It's cheap peace of mind for that exact scenario. This. You don't need anything fancy, you just need something as a backup so absolutely everything doesn't poo poo the bed when VMWare decides to take a break from life. NippleFloss posted:I'm struggling to think of anything you can do with a physical DC that you couldn't also do with a virtual DC (in addition to the other things you can only do with a virtual server). Nothing really. It's just peace of mind. Sort of the same way there's a 3-2-1 rule for backups, I can't see why it would be a bad idea to hedge your bets on your virtual environment by also having a dedicated peace of hardware running a DC. Particularly if it's handling DHCP/DNS.
|
|
#
?
Mar 11, 2016 21:24
|
|
|
Use one of the old servers you made obsolete by virtualizing.
|
|
#
?
Mar 11, 2016 21:27
|
|
|
NippleFloss posted:I'm struggling to think of anything you can do with a physical DC that you couldn't also do with a virtual DC (in addition to the other things you can only do with a virtual server). Boot a domain joined host maybe? Don't domain servers have to Auth against the DC on boot?
|
|
#
?
Mar 11, 2016 21:46
|
|
|
GnarlyCharlie4u posted:Nothing really. Your virtual environment need not be (should not be) a monolithic thing that all goes down or comes up at once. You can boot a single VM without VCenter or SCVMM running by connecting directly to the host that houses it. You can store the VM on a separate datastore or local storage if you're concerned about a storage service outage bringing everything down. RFC2324 posted:Boot a domain joined host maybe? Don't domain servers have to Auth against the DC on boot? No, you can still log in with a local administrator account to boot the DC off of the host that it lives on. Same thing you do with a virtualized VCenter.
|
|
#
?
Mar 11, 2016 21:56
|
|
|
RFC2324 posted:Boot a domain joined host maybe? Don't domain servers have to Auth against the DC on boot? Yes. But I think he's ruling out any sort of 'oh poo poo' scenario where your virtual environment shits the bed. Purely from a functional ability standpoint virtual DC's are as good as physical. Considering contingencies (failures), no, they are not. NippleFloss posted:Your virtual environment need not be (should not be) a monolithic thing that all goes down or comes up at once. You can boot a single VM without VCenter or SCVMM running by connecting directly to the host that houses it. You can store the VM on a separate datastore or local storage if you're concerned about a storage service outage bringing everything down. This still requires some immediate work on your part though. If you've got a DC still up and running, then those late night "I CAN'T DO WHATEVER THE gently caress IT IS I NEED" calls can wait till the morning. We've had vSphere not failover properly before. "Should not be" doesn't necessarily mean "absolutely won't." GnarlyCharlie4u fucked around with this message at 22:01 on Mar 11, 2016 |
|
#
?
Mar 11, 2016 21:58
|
|
|
GnarlyCharlie4u posted:This still requires some immediate work on your part though. If you've got a DC still up and running, then those late night "I CAN'T DO WHATEVER THE gently caress IT IS I NEED" calls can wait till the morning. A physical host will also not fail over so I'm not sure how "VSphere HA didn't work properly" is worse than "host has no HA." VSphere hosts work largely independent of one another so outside of network events (which would likely affect your whole environment anyway) and storage events (which can be solved by splitting your DCs across different storage) there's not much chance of your whole virtual environment blowing up while a lone u protected physical server remains running.
|
|
#
?
Mar 11, 2016 22:06
|
|
|
devmd01 posted:It's not like a 1u 1socket 8gb ram 250gb raid1 server with ipmi costs all that much. If i'm in the middle of a catastrophic vmware cluster event, the last thing I need to be stressed about is having a copy of the global catalog and basic dns resolution along with everything else going on at the time. It's cheap peace of mind for that exact scenario. Please tell me what catastrophic VMware event is going to take out all your domain controllers at once from your cluster that won't occur if one is physical. GnarlyCharlie4u posted:Yes. But I think he's ruling out any sort of 'oh poo poo' scenario where your virtual environment shits the bed. I have a feeling virtual environments you have been a part of are complete poo poo. Its like this entire post is plastered with bad design with a small dash of superstition. devmd01 posted:Purely from a functional ability standpoint virtual DC's are as good as physical. This part just makes my head hurt. I just figure if this is just lack of experience or bad mentors. Sickening fucked around with this message at 22:38 on Mar 11, 2016 |
|
#
?
Mar 11, 2016 22:22
|
|
|
After bashing my head against the wall with open source monitoring, i finally got a setup im happy with using OMD and Check_mk. Got all my hosts and network devices in it, monitoring. Goddamn this feels good not having to run around and check multiple things.
|
|
#
?
Mar 11, 2016 22:42
|
|
|
GnarlyCharlie4u posted:Yes. But I think he's ruling out any sort of 'oh poo poo' scenario where your virtual environment shits the bed. You sound like the Exchange expert that convinced our guys to buy 8 2RU dells instead of using the virtual infrastructure for the new exchange servers because there MIGHT BE PROBLEMS WITH THE VIRTUAL INFRASTRUCTURE!! Spoilers: they had hardware problems and it ended up wasting a lot of their time when they could have been doing migrations and stuff.
|
|
#
?
Mar 11, 2016 22:58
|
|
|
abigserve posted:there MIGHT BE PROBLEMS WITH THE VIRTUAL INFRASTRUCTURE!! I like to keep a single physical DC for each domain I manage. I'm fine with the rest virtualized but I still want that one physical so I don't have to deal with either Local Admin (that nobody should know and should be locked away in the password vault accessed by using none other than AD Credentials!) or hoping I have cached credentials in all the right places. That being said I run Hyper-V as the host, domain joined so there are real cases where all virtual can be an issue (like when somebody forgets to turn off time sync for domain controllers and you get a really awesome feedback look that end up having time hours out of whack). It's a cheap and easy safeguard in this case. That being said, it could be a one bitten type of thing for me. I'm also a huge virtualization proponent. To the point of "I don't care that the Only VM on that hardware will be your beast of a SQL server. Visualize it anyway so we can migrate it if we have to!
|
|
#
?
Mar 11, 2016 23:32
|
|
|
Zaepho posted:I like to keep a single physical DC for each domain I manage. I'm fine with the rest virtualized but I still want that one physical so I don't have to deal with either Local Admin (that nobody should know and should be locked away in the password vault accessed by using none other than AD Credentials!) or hoping I have cached credentials in all the right places. That being said I run Hyper-V as the host, domain joined so there are real cases where all virtual can be an issue (like when somebody forgets to turn off time sync for domain controllers and you get a really awesome feedback look that end up having time hours out of whack). Domain controllers don't have local accounts and I have no clue what in the world you are talking about when you say "cached credential". Time is always a concern with domain controllers. Saying that, the time problem is exactly the same for physical and virtual so I have no clue why you believe physical is somehow immune or any easier to deal with.
|
|
#
?
Mar 11, 2016 23:53
|
|
|
Look at all you people who have budgets for spare servers!
|
|
#
?
Mar 12, 2016 00:01
|
|
|
Tab8715 posted:This is immensely helpful. Generally speaking: A disk witness is designed for a local cluster- a cluster of servers that inhabit the same physical location and have access to the same shared storage via fiber channel or ISCSI. Local clusters are designed for high-availability within a local region, providing continuity in the event of a hardware failure or server patching or something else that might take a member server offline. A file share witness is designed for what is called a stretched database. This is where there are two database servers in different datacenters in different locations and requires a file share in typically a third location to determine quorum. Stretched database clusters are designed for regional redundancy as well as providing a low- latency local copy to any applications in theta region (think of a server pair on the east coast and west coast- with each server handling traffic from its respective side of the country.) A quorum system exists to establish with database node is to be treated as a source of truth, and any changes made to it during an outage situation are then shoved to the other members of the cluster when the outage is resolved. If you didn't have a quorum facility, if there were an even number of database servers, both halves would think that they were primary if they cannot talk to each other to negotiate changes. When they were able to resume communications, both servers would try to force changes to the other and it would be a mess. Implementing a stretched database cluster is no small chore. You need to really be careful of latency and stability of the links as well as the ability of your network links to be able to pass all your database changes in a timely manner. I hope this helps. Agrikk fucked around with this message at 00:06 on Mar 12, 2016 |
|
#
?
Mar 12, 2016 00:02
|
|
|
Isn't USN Rollback Prevention and a whole of other features added into Windows Server that prevent all the bad things from occurring to virt DCs?
Gucci Loafers fucked around with this message at 00:47 on Mar 12, 2016 |
|
#
?
Mar 12, 2016 00:44
|
|
|
Tab8715 posted:Isn't USN Rollback Prevention and a whole of other features added into Windows Server that prevent all the bad things from occurring to virt DCs?
|
|
#
?
Mar 12, 2016 00:52
|
|
|
Isn't that a post-2008 feature? Not that 2012 / R2 is particularly new but it's not uncommon to see Server 2008 R2 DCs.
|
|
#
?
Mar 12, 2016 01:00
|
|
|
NippleFloss posted:A physical host will also not fail over so I'm not sure how "VSphere HA didn't work properly" is worse than "host has no HA." VSphere hosts work largely independent of one another so outside of network events (which would likely affect your whole environment anyway) and storage events (which can be solved by splitting your DCs across different storage) there's not much chance of your whole virtual environment blowing up while a lone u protected physical server remains running. Hardware failures with the mezzanine cards in our blade chassis brought all of our on site hosts (and their VM's) to a screeching halt. One host failed, it tried to migrate the VM's to other hosts in the chassis, wound up locking up the other VM's in the process. The VM's were still "up" but they just weren't processing anything. HA didn't attempt to migrate VM's to our offsite chassis because they didn't appear as down, even though they weren't responsive. We don't need the physical DC to fail over, just be there to handle DNS and DHCP. I'm not advocating physical over virtual, but I'm not saying it's a bad idea to have both. abigserve posted:You sound like the Exchange expert that convinced our guys to buy 8 2RU dells Nobody's buying anything, we just use the servers that were left over after we virtualized everything. It's just that much less that we're decommissioning.
|
|
#
?
Mar 12, 2016 01:02
|
|
|
I don't know how many people here support some computers that aren't joined to a domain and don't have Windows update disabled, but in case you do there are reports (including me) that win7 is automatically upgrading to win10 without any user interaction at all! 
|
|
#
?
Mar 12, 2016 01:13
|
|
|
Kashuno posted:I don't know how many people here support some computers that aren't joined to a domain and don't have Windows update disabled, but in case you do there are reports (including me) that win7 is automatically upgrading to win10 without any user interaction at all! Yes. This is a thing.
|
|
#
?
Mar 12, 2016 01:16
|
|
|
Turtlicious gonna have some fun in the next few days
|
|
#
?
Mar 12, 2016 01:21
|
|
|
We have some customized PCs provided by an outside company and I assumed that someone had been messing with them and somehow got outside the locked down program to accidentally update it but nope! Driver and software issues galore. Thanks MS.
|
|
#
?
Mar 12, 2016 01:25
|
|
|
Sickening posted:Domain controllers don't have local accounts and I have no clue what in the world you are talking about when you say "cached credential". He's referring to being able to login to a server/workstation with a domain credential in the event that the network and/or domain goes away. If you've previously logged into said device with that credential it will continue to support the use of that credential despite the absence of authority. And technically DCs do have a local Admin account- It's the account that was previously the Administrator account before that server was promoted to a DC in the first place. Regardless, the only time you'd ever use it would be in the event of a DC restoration, which no one does anymore anyway. Just spin up a new DC instead. Also yes, there's no reason to have a physical DC. I'm trying to imagine a scenario where every ESX host in an ORG shits the bed simultaneously but I don't see it. It's not like vCenter going away really affects anything on a granular scale; those VMs will keep running, you'll just lose vMotion and other backend intelligence. The whole scenario is reminding me of the old SQL philosophy where SQL engine servers MUST run on physical machines. Granted, that used to be MS' stance, but still.
|
|
#
?
Mar 12, 2016 01:25
|
|
|
Boss is calling me, but you know what... I'm probably going to wait until Sunday.
|
|
#
?
Mar 12, 2016 01:28
|
|
|
Turtlicious posted:Boss is calling me, but you know what... Tell him you're already drunk and you're drinking because of the stress (don't do this)
|
|
#
?
Mar 12, 2016 01:29
|
|
|
I have 4 domains in my forest. None of them have a physical DC, and we have never had a problem. I can't think of a single scenario where VMware causes a complete AD outage. We have two datacenters, each running 2 DCs for each domain. If vcenter shits the bed, the hosts still run. If a single host fails, the DCs on it come up on the others. If vcenter and a host fail, HA still brings up the dead VMs on another host. Any network level outage is going to affect a physical DC just as much as the virtual one. The worst case scenario is a total storage failure at one site, but even then my other site is up and running. WAAAAAAY back in the day, on VMware ESX 3.5 and earlier, we did have physical DCs. There were clock drift issues with binary translation and having a physical DC helped mitigate that. Even then, we just used a desktop PC with Windows server 2003 installed on it, no need for server class hardware for it. I am pretty sure we ran a mirror of two 40GB drives on them.
|
|
#
?
Mar 12, 2016 01:32
|
|
|
Alright, so who wants to start a Splunk thread? I've been playing around with it and it's awesome, but I have hit some frustrating issues. Mostly stumbled through them, but it seems like a neat tool that would apply in most (all?) environments and can be started at a basic level for free.
|
|
#
?
Mar 12, 2016 01:40
|
|
|
How did anything even work before virtualization?
|
|
#
?
Mar 12, 2016 01:45
|
|
|
Methanar posted:How did anything even work before virtualization? It sucked. Seriously. Virtualization is the only thing that makes IT work exciting.
|
|
#
?
Mar 12, 2016 01:47
|
|
|
Internet Explorer posted:Alright, so who wants to start a Splunk thread? I've been playing around with it and it's awesome, but I have hit some frustrating issues. Mostly stumbled through them, but it seems like a neat tool that would apply in most (all?) environments and can be started at a basic level for free. I was looking for one a while back, disappointed to not find one.
|
|
#
?
Mar 12, 2016 02:00
|
|
|
Sickening posted:Domain controllers don't have local accounts and I have no clue what in the world you are talking about when you say "cached credential". I meant Local Accounts on the Host OS (Hyper-V). Cached Credentials as in when you can log into the machine with a set of credentials that the OS has cached from a past login when a DC is not available to perform authentication. (https://technet.microsoft.com/en-us/library/hh994565.aspx) The Time sync issue is when the Virtual DC is having it's hardware clock synced with the Hypervisor's clock and the Hypervisor clock is syncing to the DC. Virtual machines lose time. This is an absolute constant. This results in a feedback loop causing the time to get further and further out of whack causing all sorts of lovely issues. I know all about this one because it happened to me when I let management talk me into foregoing physical DCs and somebody goofed and built a new DC without disabling time sync with the hypervisor. The time deltas brought everything to a complete standstill.
|
|
#
?
Mar 12, 2016 02:02
|
|
|
Internet Explorer posted:Alright, so who wants to start a Splunk thread? I've been playing around with it and it's awesome, but I have hit some frustrating issues. Mostly stumbled through them, but it seems like a neat tool that would apply in most (all?) environments and can be started at a basic level for free. It might be prudent to have a general "centralized logging/data collection" thread. Splunk is definitely the king of that particular mountain, but it will probably be more successful with a wider range of products and technologies. quote:The Time sync issue is when the Virtual DC is having it's hardware clock synced with the Hypervisor's clock and the Hypervisor clock is syncing to the DC. Wait, people actually do this? Or is this a holdover from when virtualization providers could only pull time from an internal source on the network? I don't have any direct experience with that configuration but I can't believe that would've ever been "the norm." Feel free to correct me though. Wrath of the Bitch King fucked around with this message at 02:31 on Mar 12, 2016 |
|
#
?
Mar 12, 2016 02:26
|
|
|
Why do help desk jobs require degree in Computer Science? I can understand for coding jobs but this feels really random.
|
|
#
?
Mar 12, 2016 02:35
|
|
|
Zaepho posted:I meant Local Accounts on the Host OS (Hyper-V). Again like i said before, I understand the time issue and they happen physical machines as well without the right controls in place. Putting a punch of dc's on the same physical host was not a good idea and it wasn't just for the time problem. You had the right idea in a way with using a second server to spread your dc's, but confused the reason being that it was physical that it gave you any sort of added redundancy. Time is something that should be monitored on DC's and sync'd with an external time server, enforced through group policy. There shouldn't be any mistakes of your DC's changing time at randomly in a controlled environment. Wrath of the Bitch King posted:Wait, people actually do this? Or is this a holdover from when virtualization providers could only pull time from an internal source on the network? I don't have any direct experience with that configuration but I can't believe that would've ever been "the norm." Feel free to correct me though. Your servers/workstations sync their time with domain controllers. Your domain controllers sync time with their local hardware if they aren't configured not to. You control this through group policy and syncing with an external NTP server. Sickening fucked around with this message at 02:40 on Mar 12, 2016 |
|
#
?
Mar 12, 2016 02:38
|
|
|
Wrath of the Bitch King posted:Wait, people actually do this? Or is this a holdover from when virtualization providers could only pull time from an internal source on the network? I don't have any direct experience with that configuration but I can't believe that would've ever been "the norm." Feel free to correct me though. I think it's the default. At my last job this caused gradual time problems until I set up a lovely physical PC that just handled time.
|
|
#
?
Mar 12, 2016 02:40
|
|
|
Alder posted:Why do help desk jobs require degree in Computer Science? Because HR people write that requirement, not IT people
|
|
#
?
Mar 12, 2016 02:40
|
|
|
Dr. Arbitrary posted:I think it's the default. The virtual server and the physical dc's had one thing in common, they pulled their time from their local hardware by default. The solution you provided was just to use a different local hardware clock. The best method is to use an external source.
|
|
#
?
Mar 12, 2016 02:42
|
|
|
|
| # ? Jun 9, 2024 19:38 |
|
|
Sickening posted:Your servers/workstations sync their time with domain controllers. Your domain controllers sync time with their local hardware if they aren't configured not to. You control this through group policy and syncing with an external NTP server. I get it, I just thought that pointing to an external NTP source was the norm. I didn't think that people DIDN'T do that.
|
|
#
?
Mar 12, 2016 02:44
|
|